Re: [gtk-list] Weird behavior - memory gets sucked up

[beach Ataman COM]

On Fri, Oct 30, 1998 at 07:50:23AM -0800, Eric Harlow wrote:

> I'm writing a sample program that reads in apache log files for
> analysis.  As part of that, I display a progress bar in case they have
> these really *large* log files that they're trying to view to let them
> know how far the read is going. 
> 
> I did this when I found out how slow it was to call
> gtk_progress_bar_update every iteration.  (Probably because if I have
> a 100000 line log file, the damn progress bar is updating after every
> call - me thinks the code in the progress bar should be changed from a
> delta floating point comparision to an integer comparision.  Do you
> really want to update the progress bar if the % has changed from
> .1000000 to .1000001?  But I digress.)

As for the memory leak, you may have found a real bug, I don't know...
I'm not an authority on this thing.

> 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.

-- 
David J. C. Beach <beach@ataman.com>
Ataman Software, Inc.