[Pharo-project] Waste of CPU Power by polling events?

John M McIntosh johnmci at smalltalkconsulting.com
Fri Nov 26 23:40:30 CET 2010

Eliot, I had looked at turn off the heartbeat when we did the nanosleep, then turned it back on.  The problem was actually trying to figure out if 
it did any good since the cost of  pausing/restarting the heartbeat task was high. I think first we have to quantify the costs. This is difficult to do on desktop 
machines since they are so fast, so I was working with an iPod touch which is 1000x (wild guess number) times slower. 

I'm also unsure of the pattern for when the ioRelinquishProcessorForMicroseconds is called and for how long. Further to that we do attempt to calculate the next wake up time, but sometime it's in the past, so why is ioRelinquishProcessorForMicroseconds being called? Even if we sleep then how long and what wakes us up early? 

On 2010-11-26, at 8:39 AM, Eliot Miranda wrote:

> Yes, we need to change this, but I think one has to change the background process and/or nothing to run behavior.  In the VW VM the VM disables the heartbeat and enters some blocking call when there's nothing to do.  Squeak runs the background process which calls a primitive that sleeps for a short time.  The former is much better.  If a delay is active as the VM does to sleep it schedules a wakeup event or supplies a timeout so that it blocks until input is available or the next delay.
> We could still keep the background process and do something similar to VW, disabling the heartbeat until after the relinquish, and factoring the delay into the relinquish timeout.
> Also the heartbeat already has facilities to change its frequency, so one could modify things to slow down the heartbeat, again ensuring that it ticks before the next delay expiry.
> What approach (not necessarily from the above) appeals to you John?
> best
> Eliot

John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20101126/cb2759e4/attachment.htm>

More information about the Pharo-project mailing list