Re: [be] Re: bibledit-git polling

[Teus Benschop]

I've read your previous posts too. It seems to be that g_usleep is more
expensive on Windows than on Linux. On Linux it too does use a bit of
CPU time, while I had expected to to use none. The problem occurs on
Linux too, but is much smaller than on Windows. I suppose that the
expansion of the time from 100 microseconds to the 10000, if the
response time is still good enough, is a good interim solution, while I
have to look into other ways of resolving this. Well, if the g_usleep
(10000) does the job well, we might as well stick to that. I'll check on
Linux what it does. Thanks for looking into this. Teus.

On Wed, 2009-01-28 at 19:15 -0800, Dan Dennison wrote:
> Another follow-up on this..
> 
> I changed the g_usleep interval from 100 to 10000 and bibledit-git no  
> longer polls on Windows!
> 
>      while ((method_called_type != method) && (time(0) <= (oldtime +  
> timeout))) {
>        g_usleep(10000);
>      }
> 
> Thoughts?
> 
> dan :)
> 
> On Jan 28, 2009, at 6:43 PM, Dan Dennison wrote:
> 
> > On Jan 28, 2009, at 4:53 PM, Dan Dennison wrote:
> >
> > I built bibledit-git using the '-pg' option. This results in gprof- 
> > style outputs.
> >
> >> I need to double-check this on Windows, but it seems to me off-hand  
> >> that this loop is going to be CPU-expensive regardless of platform.  
> >> bibledit-git is so expensive CPU-wise on Windows right now that  
> >> it's hard to recommend for laptop users.
> >
> > See my gprof output for details, but  
> > InterprocessCommunication::receive() is the most expensive function  
> > on Win32, with a tie between vector manipulations (likely from  
> > InterprocessCommunication::get_payload()), and g_usleep().
> >
> > It seems that every call to g_usleep is invoking a thread. I think  
> > perhaps thread spawns are much slower on Win32, and thus the CPU  
> > slamming.
> >
> > GProf output is at https://thedennisons.org/~dand/bibledit-git- 
> > gprof.txt.gz
> >
> > Thoughts?
> >
> > dan :)
> 
> 
> 
>