[squeak-dev] Re: Usability and look-and-feel
gaelli at emergent.de
Thu Jul 9 22:34:21 UTC 2009
Am 09.07.2009 um 23:30 schrieb stephan at stack.nl:
> Lukas wrote:
>> It is definitely not an issue of OB, but an issue of the extensions
>> that people load with OB.
>> If you try the Seaside One Click image you will notice that OB is
>> marginally slower than the old browser.
> Some supporting numbers:
>> [ToolSet default browse: Behavior selector: nil] timeToRun.
> 3869 Pharo 10342
> 2962 Pharo 10292
> 1767 Pharo 10243
> 1410 Pharo 10074
> 670 Pharo 0.1-PolymorphTT (Non OB)
> 560 Seaside-2.8-578 (OB)
> 395 3.9-7067dev (non-OB Package browser)
> 2GHz core duo/XP
Another data point: Squeak 3.1, Mac 2.53 GHz core duo/OS-X 10.5.7 with
a new vm:
Browser fullOnClass: Behavior selector: nil. (not: ToolSet default!)
For MVC I had to do a little hack, so I am not totally sure if this is
The current process is terminated when the controller switches to the
new browser. (See ControlManager >> scheduleActive: )
So I actually used the following snippet to start the browser:
TimeDiff :=Time millisecondClockValue.
Browser fullOnClass: Behavior selector: nil.
after tweaking in some TimeDiff measurement into the following method:
ControlManager scheduleActiveNoTerminate: t1 (too lazy to bother for
sources right now)
self schedulePassive: t1.
self scheduled: t1 from: Processor activeProcess.
TimeDiff:=Time millisecondClockValue - TimeDiff.
as this method seems to be the last called before termination of the
ControlManager >> scheduleActive: t1
<primitive: 19> "primitiveFail"
self scheduleActiveNoTerminate: t1.
TimeDiff then yields 8!
Please proof me wrong and/or help to bring MVC back to live in current
eg. having some midi-synth on the iphone wouldn't need energy draining
More information about the Squeak-dev