[squeak-dev] squeak profiling
yoshiki at vpri.org
Mon Apr 21 23:10:47 UTC 2008
For OLPC Nepal, the backward compatibility from Squeak3.2 wouldn't
needed. So, In ImageSegment>>comeFullyUpOnReload:, the part below can
arrayOfRoots do: [:importedObject |
((importedObject isMemberOf: WideString) or: [importedObject isMemberOf: WideSymbol]) ifTrue: [
importedObject class = WideSymbol ifTrue: [
Symbol hasInterned: importedObject asString ifTrue: [:multiSymbol |
multiSymbol == importedObject ifFalse: [
importedObject becomeForward: multiSymbol.
(importedObject isMemberOf: TTCFontSet) ifTrue: [
existing _ TTCFontSet familyName: importedObject familyName
pointSize: importedObject pointSize. "supplies default"
existing == importedObject ifFalse: [importedObject becomeForward: existing].
The real gain would come if we cut out inefficiency in
SmartRefStream around the class shape change and the nested structure
from DataStream. Is there something we can primitivized around it?
A simple entry point for profiling project loading would be
MessageTally spyOn: [ProjectLoading loadFromDir: '/usr/share/etoys/ExampleEtoys' projectName: 'DemonCastle1'].
"Near Venice"... That almost made me want to fly there^^;
At Mon, 21 Apr 2008 12:39:28 +0200,
Riccardo Lucchese wrote:
> Dear Bert,
> > Anyway, we greatly appreciate help, in particular on the OLPC platform.
> > Great to have a summer-of-code student on board! I am one of the core
> > developers for the OLPC version of Etoys. We have an OLPC-specific mailing
> > list at
> > http://lists.laptop.org/listinfo/etoys
> subscribed :)
> > This list here is for general Squeak topics, there's nothing too hard to
> > ask, the fine folks around actually like answering tough questions (just not
> > the kind of very basic "what do I have to do to execute code" type
> > questions). The virtual machine hackers have their own list, as most folks
> > here are quite happy not having to deal with C anymore:
> It's ok, they were very nice to me :). I just stopped posting as I was trying
> to understand more of squeak/etoys before giving any feedback.
> > Most optimization possibilities I see are on the Smalltalk-level anyways.
> > And it's possible to get quite some speed improvements there - like what
> > Ties Stuij of OLE Nepal did, who is new to Squeak, too, and already improved
> > project loading time quite a bit (granted, he was "initiated" by Luke Gorrie
> > who had hands-on training be me - your best bet to get up-to-speed would be
> > to find a Squeak hacker near you. Where are you located?)
> I live near Venice in Italy.
> > On the VM-level I see some improvement possibilities in particular in
> > drawing speed. We use a generic BitBlt implementation for everything.
> > Rotated bitmap display ("WarpBlt") is taking quite some time on the XO due
> > to its incredibly high-resolution display. 1200x900 pixels make a lot of
> > bits to push around for the little Geode CPU. Recoding the inner WarpBlt
> > loop in MMX for example could gain quite a lot, also the color-format
> > conversion (Squeak is 5-5-5, the X server uses 5-6-5).
> My main goal is profiling Sugar and I don't think that I'll be able to work
> on the st part of squeak; will see :)
> I'll mail you directly (hope it's ok) and stop the noise here :)
More information about the Squeak-dev