[Pharo-project] Speeding up Pharo 1.1

Levente Uzonyi leves at elte.hu
Sun Oct 17 12:17:22 EDT 2010


On Sun, 17 Oct 2010, Henrik Johansen wrote:

>
>
> Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves at elte.hu>:
>
>> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed.
>>
>>
>> Levente
> It doesn't, there's effectively polling done in the UI threads hand processing on Squeak.

I see. But MessageTally doesn't:

MessageTally spyAllOn: [ 10 seconds asDelay wait ]

Squeak:
**Leaves**
99.7% {9970ms} ProcessorScheduler class>>idleProcess

Pharo:
**Leaves**
89.9% {8990ms} ProcessorScheduler class>>idleProcess
10.1% {1010ms} Delay>>wait

>
> If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it.

Okay, so the windows VM doesn't signal the semaphore. It could/should 
still be used at least on other platforms.
A mixed system is also possible, because one can wait for a semaphore 
signal with a timeout. So for windows the timeout can be 10ms, while on 
other platforms 1000ms.

Also waiting for 10ms, no matter how long the event processing took is a 
bad idea IMHO. Waiting for a total 10ms (which includes the time spent 
during processing the events) results in a more responsive system.

Btw why doesn't the windows VM signal the semaphore?


Levente

>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>




More information about the Pharo-dev mailing list