Re: [be] bibledit-bin CPU usage

[Teus Benschop]

Yes, this is a point that needs to be addresses so that CPU usage is
reduced even further. I've been noticing the idle CPU usage on my laptop
to be about 2% and thought this was high, but never got round to see
where it came from. Thanks for getting to the cause of the CPU time
consumption. If you'd like to use a hash table, that will greatly
improve the matter, and in that case the hash table functions provided
in GLib would be preferred as these are already available to us using
the current set of libraries we link to. There are two other solutions I
am thinking of. One is that last the key and value of last lookup are
stored, so that a new lookup is only done when the key changes. And
another solution is to look into the option whether the function cannot
be made a callback in response to an event that triggers a style change,
but this solution will be more complex. I'll need to look into this
matter soon so as to apply a good solution. Teus.

On Sat, 2009-01-31 at 16:47 -0800, Dan Dennison wrote:
> I ran bibledit-bin on Linux through callgrind, which is part of  
> valgrind.
> 
> It seems the bulk of its idle CPU usage is in the following fragment,  
> located in editor_aids.cpp:
> 
>    for (unsigned int i = 0; i < usfm->styles.size(); i++) {
>      if (marker == usfm->styles[i].marker) {
>        type = usfm->styles[i].type;
>        subtype = usfm->styles[i].subtype;
>        break;
>      }
>    }
> 
> This fragment is called every verse_tracker_timeout. Of the 51  
> verse_tracker_timeouts captured by my sample, 43,880 calls were made  
> to ustring::compare, which is called during evaluation of the if  
> statement. Quick math shows about 860 calls to a string comparison per  
> verse_tracker_timeout.
> 
> I think I might be possible to optimize the loop out completely by  
> using a hash table to do the lookup here. This is significant because  
> the idle CPU draw from bibledit-bin can be then further reduced,  
> allowing for even greater laptop battery life, crucial for some of our  
> deployment scenarios.
> 
> What do you think? My callgrind output is at https://thedennisons.org/ 
> ~dand/callgrind.out.19357.gz
> 
> dan :)
> 
> 
>