[9702] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: Weird behavior - memory gets sucked up
daemon@ATHENA.MIT.EDU (Eric Harlow)
Fri Oct 30 23:56:51 1998
Date: Fri, 30 Oct 1998 21:00:13 -0800 (PST)
From: Eric Harlow <linuxgeek@yahoo.com>
To: gtk-list@redhat.com
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
> > Putting the code in a block that gets called 100 times (as
opposed to
> > 10000 or so) seemed to significantly reduce the memory footprint.
The
> > gtk_progress_bar_update function needs to be called in the loop to
> > cause the leak. For my really large log file, the old code ends up
> > acting like an MS app - sucking down 90% of memory and causing disk
> > swap.
>
> Yes, and this is the right thing to do. Even if
> gtk_progress_bar_update() used an integer comparison instead of a
> floating point wouldn't help you as much as you'd like. Why would you
> want an extra function call overhead in your loop if is that size,
> anyway? Far better to only call once every 10 or 100 lines. This
> also dedicates more CPU to actually reading the file instead of
> updating the progressbar in ways that no human can appreciate. Even
> if the progressbar checked before doing an update (even with an
> integer comparison), you'd still lose a considerable amount of CPU
> that could be used to read/process your file --- not a good tradeoff.
>
> Can you think of a situation where it would be useful to update the
> progress bar after every processed line? Given the speed with which a
> line is processed and the purpose of a progress bar, I cannot.
I think that a library should be smart enough to know when a
programmer is being inefficient. In the first pass of developing
code, getting the code to work is the first priority. Once working,
the speedup/cleanup begins.
In my case, I was using small files to do some testing. Once I got
the basic bugs knocked out, I tried to import a 10 meg file - bad move.
The two slowest part of the operation became the repainting of the
progress bar instead of the file i/o. The library should be smart
enough to say - hey, the progress bar didn't move, don't bother
updating. I *shouldn't* have to write that code myself. I *could* if
I wanted to speed it up a bit after it was working.
-Eric
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
