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  
>> only
>> 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!)

Morphic: 85
MVC: 8

For MVC I had to do a little hack, so I am not totally sure if this is  
true:
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  
caller process:
ControlManager >> scheduleActive: t1
	<primitive: 19> "primitiveFail"
	self scheduleActiveNoTerminate: t1.
	Processor terminateActive

TimeDiff then yields 8!

Please proof me wrong and/or help to bring MVC back to live in current  
Squeak --
eg. having some midi-synth on the iphone wouldn't need energy draining  
morphs...

Cheers

Markus