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

[Jan Gentsch <gentsch ifm uni-hamburg de>]

Eric Harlow wrote:

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

That point isn't totally off. But hey you are talking about a progress bar,
meaning about an operation which is expected to take a lot of computaion time.
Now you should ask yourself what is it that swallows the time so I have to
keep my user entertained. It's is certailny not reading in a single line, it
is reading large blocks of lines and that is the point where you should use
the progress bar. Even if the progress bar is not being updated (repainted
really) the work to entertainement ratio is still to low if you are updating
after every line. In that sense you are missusing the idea of the progress
bar. Why don't do something like this:

for(i=0; i<500; i++)
   {
   if(EOF==fscanf(...));
        break;
   }
-->update progressbar here

And of course you should call this via an idle callback, in order to allow the
user to press the 'Cancel' button which you have of course provided in case
your user has changed his/her mind. You say yourself that your code is
inefficent. I believe that is because you haven't analysed the task you trying
to accomplish in enough detail. The decision when to update the progressbar is
one to be taken by the programmer not by the widget.

Regards,
Jan