[Xastir-dev] Re: Another case of high load

[Henk de Groot]

Hello Curt,

At 13:30 9-9-2004 -0700, Curt, WE7U wrote:
>Problem is, that function is called all over the place, so you might
>slow down the main processing loop too much by doing that.  What
>happens if you use "usleep(1);" though?  That might be do-able.

I also added a big usleep on the check_statusline_timeout function, which 
is part of the big UpdateTime loop. It turns out that that was the sleep 
that removed the load, not the sleep in the statusline functions (I 
checked, this one is only called when there is something new).

I tried to increase the "nexttime" value which is there from problems in 
the past. First I tried to bump is up slowly, 3, 4, 5. At 5 the load 
decreased a little, lsass.exe burns 15% cpu. Then I set it to 10, the load 
on lsass.exe decreased to 11%.

When I use 100 the load is gone, except that I see an activity boost every 
second.

I suspect that something has changed in Xwindows, otherwise I can't 
understand why the problem surfaced again, you added this delay ages ago.

Okay, bumping up nexttime too high is not nice, so I tried something else. 
At the very last line of UpdateTime I added a "usleep(2)" for force 2 micro 
seconds extra delay. Well, that works, the load on lsass.exe dropped to 8%. 
Changing usleep(2) to usleep(100) didn't help more however(!). So I added 
two times usleep(2) instead. Load on lsass.exe dropped to 8% with that.

Aparently the granularity of XtAppAddTimeOut ans usleep it not fine-grained 
enough (on Cygwin). My guess is that whatever small value you use on 
usleep, it will at least wait one timer-tick; so two times usleep(2) adds 
more time than once usleep(100)...

Anyway, this part is very implementation dependent as it is now. I guess a 
real solution is to rewrite this. Keep a sorted timer list and just sleep 
until the next timer will run off, that's much more efficient and robust 
that the polling mechnism we have now (but of course more complex code).

Met vriendelijke groet,

Henk.