[Etoys] Slow etoys project loading for EPaati
Luke Gorrie
luke at member.fsf.org
Thu Feb 7 04:23:16 EST 2008
So it seems to have been fairly easy to more than double the speed of
loading our slowest-loading project (names of colors.pr), but I'm not
certain that the fix is correct. The logic seems right but I've
noticed Squeak getting wedged with 100% CPU usage and I'm not sure
whether my change is causing this.
The change is to hack ImageSegment>>restoreEndianness to more
efficiently rehash MethodDictionary objects. MethodDictionary>>rehash
uses #become: and that's expensive -- on my 1.6Ghz machine #become:
takes about 50ms on each of our hundreds of instances. Taking a cue
from the 'Back to the Future' paper [*] it seems like a good idea to
combine all of the #become:'s into a batch so that the heap is only
traversed once, like this:
ImageSegment>>rehashMethodDictionaries: oldDictionaries
| newDictionaries |
newDictionaries := oldDictionaries collect: [:d | d rehashWithoutBecome].
oldDictionaries asArray elementsForwardIdentityTo: newDictionaries asArray.
This pulls the loading time of that project on the XO down from 3.5
minutes to 1.5 minutes, which is still too slow but progress is
progress :-)
ChangeSet attached! Can someone who Knows say if it looks right?
Cheers,
-Luke (torn between speed vs. memory profiling next)
P.S. Thanks Bert for the profiling tutorial :-)
[*]: http://www.s1on1.com/main/index.cgi/000000A/http/users.ipa.net/~dwighth/squeak/oopsla_squeak.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rehashMethodDictionaries.3.cs
Type: text/x-csharp
Size: 2576 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/etoys/attachments/20080207/e7f7189f/attachment.bin
More information about the Etoys
mailing list