Screen damage logic
Dan Ingalls
Dan.Ingalls at disney.com
Thu Mar 23 00:21:54 UTC 2000
"Lex Spoon" <lex at cc.gatech.edu> wrote:
>> Anyway, once we've identified some specific operations that are slow, we
>> can run the profiler and/or think about how the code works, to try and
>> see why it's slow. Then we can make real progress, or at least make a
>> rationale tradeoff. The best people to do this stuff, of course, are
>> people with ~100 MHz computers :)
>
>For example. I notice that the World menu takes about half a second to
>pop up on my computer
>...
> 4. 15% spent in buildWorldMenu. Now we're talking--why in the world
>would it take so long to build a stupid 15-item menu? Ahhh. It is
>running "self world project", which ends up scanning all of memory to
>find the relevant project. I'm not sure what the best way to optimize
>this is, but it clearly makes a difference. I'll turn on the
>simpleMenus preference for now, thus disabling the offending menu item,
>and now the Word menu is quite zippy.
As is frequently the case, there is a very simple solution.
FileIn the following method in which the first executable line will
almost always succeed instantly:
!Project class methodsFor: 'utilities' stamp: 'di 3/22/2000 16:07'!
ofWorld: aPasteUpMorph
"Find the project of a world."
"Usually it is the current project"
self current world == aPasteUpMorph ifTrue: [^ self current].
"Inefficient enumeration if it is not..."
^ self allSubInstances detect:
[:pr | pr world isInMemory
ifTrue: [pr world == aPasteUpMorph]
ifFalse: [false]]
ifNone: [nil]! !
There. Now you can turn off the simpleMenus preference again.
I will include this in the next updates.
- Dan
More information about the Squeak-dev
mailing list
|