`just slow it`....

Stefan Matthias Aust sma at 3plus4.de
Sat Feb 10 15:58:14 UTC 2001


At 21:33 08.02.01 -0800, Dan Ingalls wrote:

>I'm jammed right now, but it would be great if someone would do a 
>tallySends: for opening a browser.  This gives exact counts, instead of 
>just timer hits.

Let's see what we can do here.

I tried to do the tally sends thing but the default VM didn't have enough 
memory.  Grrr.  My System has 256MB, why can't Squeak automatically 
allocate more memory?  Is this yet another leftover from how the MacOS 
works?  Whatever, when I tried to assign more memory to my Squeak, I 
stumbled over a small bug.

squeak -memory:120

didn't work as excepted but also didn't throw an error. It allocated just 
20 MB instead of 120.

squeak -memory: 120

did what I want.  BTW, why in the name of whatever god are the command line 
options different (and only slightly different) between platforms.  That's 
really annoying.  Actually, I'd prefer if the unix version would keep the 
usual unix standard using "--" to start options.

It would also nice, btw, if the unix vm would issue a warning but not a 
throw a segmentation fault if there's no display.  Even better would be of 
course, if it would automatically work in text mode :-)

Back to the topic.  I did the tallySends thing, it took a minute or so 
while winamp was playing a piece of touch'n'go and the results are quite 
interesting.

The lists for the PluggableListMorph are not created twice because there're 
recreated once the #hightlightSelector: method is called.  Each time, 166 
StringMorph objects are created.

But wait, what happened to the debugger.  It automatically steps over all 
assignments, only stopping at message sends.  You also cannot step into 
simple getter methods.  Is this a new, intended behavior?  I dislike that.

When the browser is openend, initializing the SystemWindow already triggers 
multiple changed calls (which are harmless as the windows isn't mapped yet 
but still are superfluous) because colors are assigned twice or trice. 
"StringMorph new contents: ..; font: ..." also triggers measuring the 
string trice, sending superfluous #changed into the world and is absolutely 
stupid as this isn't even the browser label but just a temporary string 
'later'.  There're complex dependencies between morphs as each morph try to 
be displayable all the time and also reacts to any property change with a 
redisplay.  And it seems, that these dependencies aren't well understood by 
parts of the system.

So only for initializing the SystemWindow, more than 10 #changed and a 
couple of additional #layoutChanged messages were sent.  Furthermore, the 
label got #fitContents four times.

Instead of assigning colors explicitly in the morph's initialize method, 
one should provide #defaultColor, #defaultBorderColor methods with are 
called in that method and then are overwritten in subclasses.

When the categories list is constructed, even more #changed messages are 
generated when the strings are calculated.

More than 10000 calls to MorphExtension>>valueOfProperty:ifAbsent: take 
place while this all happens.  5600 times, the morph is asked wether it has 
a wonderland texture.  The rest are calls for a rollover border, a 
dropshadow border and the layout frame object.  More than 9000 rectangle 
objects are generated while the system window builds itself.  2972 times it 
is notified about changes.

All these operations aren't expensive, but they sum up.

Commenting out the #hightlightSelector: call which didn't had any impact 
anyhow, saved

calls  to
1000   MorphExtension>>valueOfProperty:
1800   Rectangle>>setOrigin:corner:
1700   Point>>+
1500   Morph>>wonderlandTexture

and so on.  The simulation was 15% faster - however in both times I used 
the computer to read emails etc, so I'm not sure whether this is an 
accurate measurement.

I can get another 10% speedup by modifying MorphExtension. I made 
layoutProperties an instance variable.  So that the objects don't get 
larger, I made "actorState" a property.

A change it attached, the message sends are available upon request - 
they're big.

bye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Improvements-sma.1.cs.gz
Type: application/octet-stream
Size: 6657 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010210/c2f5087f/Improvements-sma.1.cs.obj
-------------- next part --------------
--
My eyes adapted to the darkness... finally I can see clearly now


More information about the Squeak-dev mailing list