primus has asked for the wisdom of the Perl Monks concerning the following question:


hail monks,

recently i have been playing around with win32::gui and Tk, and i just cannot seem to keep the memory usage to a minimum.

i would love to know the tricks of the trade behind conserving memory and making efficient applications. are there any good tutorials that are tried and true? does anyone have any knowledge regarding the subject that they would like to share?

i think this is really important, and it is something i am quite the newbie at. i hope that some of the fellow monks out there will tell their stories and spread the wealth, so that we may all learn from one another.

thanks monks

Replies are listed 'Best First'.
Re: talking about memory...
by graff (Chancellor) on Feb 09, 2003 at 08:40 UTC
    That's kind of a vague question, so here's a vague response:

    What are you hoping to see as a "minimum"? What comes across as "excessive" for you? GUI's in general, and script-based GUI's especially (as opposed to hand-crafted compiled ones), tend to chew up a lot of memory beyond what you might think is reasonable -- and there's just no getting around that. It's the price you pay for the conveniences of rapid code development and highly adaptable interface designs.

    Since most machines in operation today have RAM in the hundreds (or at least several dozens) of MB, along with more hundreds (or a few GB) in virtual memory, keeping a GUI's memory footprint slim is not something we need to worry about. Making sure it's as fast as possible is much more important (you can't make people wait when it comes to responding to clicks and drags with the mouse).

    If the application involves dealing with huge amounts of data (e.g. hundreds of MB of images or whatever), in addition to running the GUI, it's the data loading that you need to be careful and skimpy about -- and note that the loading and writing of a large data set is usually the biggest component of "unacceptable delays" in GUI response.

      I know this is stepping a little bit aside from the original question, but I was wondering about the practicality of starting with Perl and gradually replacing Perl code with C code once the design is complete. It seems like the best of both worlds: rapid development of the script-based GUI, followed by efficient usage of compiled programs.

      The only problem is that once I start with the script-based project, the design never seems to look "complete". There's always one more little adjustment, or one less buton.

      Well, that's not the only problem. The other is that I've never tried a C interface to my Perl code. I hear a lot of horror stories, and I get scared easily.

      I wandered a bit there, but the question was: how practical is it to prototype in Perl, then interface or replace with C code as the project progresses? Would that address the memory concerns that primus had?

      I just realized that I was using the same sig for nearly three years.

Re: talking about memory...
by Courage (Parson) on Feb 09, 2003 at 08:37 UTC
    Following node: why does this array take up so much memory? contains some questions about memory usage and received some guidelines from others, including me.

    A question about general usage of memory is too generic, try giving us more concrete examples. May be some excerpts from code.

    Both memory and speed questions are interesting to solve, and it is widely known that Perl tries to increase speed of running programs and is much less bothering about memory.

    Courage, the Cowardly Dog

Re: talking about memory...
by primus (Scribe) on Feb 09, 2003 at 18:52 UTC

    well, thanks for the replies, i suppose a more concrete response would be that on my win32 machine, i have a fairly simple program that fetches information from the internet and displays it in a gui format, and then will autoupdate off of the internet every 20 minutes or so.

    right now with Tk, it peaks at using 11MB of memory and with win32::gui about 9MB of memory. these numbers just seem a little high for what this program has to accomplish.

    i kinda just wanted to know what maybe an "average" gui program of a generic style... nothing fancy, would run at. i am not complaining, and i really do not wish to abruptly bring down that mem usage, i just want to know if that is acceptable.
      Well, since you're using Win32, you should get PSTools from SysInternals and get a "better" profile of when/where your app is using memory. I've whipped up a demo of what I'm suggesting:

      C:\>perl -e "print grep(/Perl /,qx[pslist -m Perl])" Name Pid VM WS WS Pk Priv Faults NonP Page PageFile Perl 1632 28236 1416 1416 592 355 2 13 592 C:\>perl -MWin32::GUI -e "print grep(/Perl /,qx[pslist -m Perl])" Name Pid VM WS WS Pk Priv Faults NonP Page PageFile Perl 1516 34000 3200 3208 2680 802 3 17 2680 C:\>perl -MWin32::GUI -e "$main = Win32::GUI::Window->new(-name => 'Ma +in' , -width => 100, -height => 100);print grep(/Perl /,qx[pslist -m Perl] +)" Name Pid VM WS WS Pk Priv Faults NonP Page PageFile Perl 1632 34000 3240 3248 2684 812 3 17 2684

      By sprinkling pslist in your app and logging its output, you should get a better idea about what's going on. BTW, 'WS' is the number reported by Task Manager.

      Update: Added column headings to the pslist output for clarity.

      --
      Don't be too proud of this technological terror you've constructed...

      It seems reasonable to assume that such GUI programs have a high "start-up"' cost in memory, but that adding a few extra buttons and other widgets will not increase the memory consumption in a linear way.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law