"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