[Pharo-project] Speeding up Pharo 1.1

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sun Oct 17 14:46:58 EDT 2010


I don't know why the Windows VM does not signal the semaphore.  There are, of course, good and bad possible reasons why that might be.  

The up side includes possible motives of compensating for weirdness in the Windows event queue over the many versions.  Dolphin tries to be correct about it, and it took some effort; arguments could be made that they failed to get it right across all platforms (I recall having troubles with COM servers failing to run at times with the default event loop); OA dropped official support for Win2k years before that was appropriate (if it is even now), and the message queue appeared to be at the center of it.  Correct me if I'm missing a combination of versions, but every time I have tried an old Squeak image and a modern vm on any old version of Windows I happened to have handy, dragging time image onto the vm worked.

The bad part of waiting with a timeout is that the system runs (good) even when it is not properly managing the message queue, masking the problem (bad).  As Levente suggets, one way to react to this is to ensure that the Linux and Mac vms do not need the timeout. 



________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves at elte.hu]
Sent: Sunday, October 17, 2010 12:17 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Speeding up Pharo 1.1

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
>

_______________________________________________
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