Re: talking about memory...

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.

Comment on Re: talking about memory...

Replies are listed 'Best First'.
Re: Re: talking about memory... by webfiend (Vicar) on Feb 09, 2003 at 16:52 UTC
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.	[reply]

Replies are listed 'Best First'.

Re: Re: talking about memory...
by webfiend (Vicar) on Feb 09, 2003 at 16:52 UTC

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.

[reply]