Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

mac vm startup time
by John M McIntosh 25 Feb '05

25 Feb '05

I'm sure someone today muttered about the slow image startup time. A year or more back I looked into this and fixed some mac menu startup delays and we adjusted initializeObjectMemory to avoid excessive iterations over the image to fix things up. But that was awhile ago so this evening I took a look again. On my powerbook with lots of other things running an image startup, from the point of application launch to the request to draw to the window takes 1100 milliseconds. Actually I'm also watching a DVD too so I'm sure things are a bit faster on the machine if nothing else was going on. Of which: a) 225ms is taken to the point of image reading, mostly in mac menu bar creation/menu management. Some api call stacks are 48 levels deep. Not much you can do here. b) 150ms to read the image from disk/buffers (not much you can do about that) (19.2MB) image file c) 50ms to run adjustAllOopsBy: (this looks at every object and adjusts the oops (maybe depending on starting address of oop in memory)) d) 25ms to run flushExternalPrimitives (mmm perhaps that should be combined in adjustAllOopsBy:? Someone could look at that?) So it is about 450ms to get us to this point. Now the interpreter loop starts to run a) 75ms in loading modules and read directory information When plugins are first called we attempt to find them as plugins before hunting for them internally, this requires disk i/o to search (in multiple places) for the nonexistent plugins. b) someone wastes 20ms doing a nextInstance lookup Lets see what's the call stack? 116324392 Behavior>allInstancesDo: 116324300 ExternalAddress class>startUp: 116324208 ExternalObject class>startUp: 114043140 [] in SystemDictionary>send:toClassesNamedIn:with: 114042916 OrderedCollection>do: 114042824 SystemDictionary>send:toClassesNamedIn:with: 114042732 SystemDictionary>processStartUpList: 113811996 SmalltalkImage>snapshot:andQuit:embedded: 113811904 SmalltalkImage>snapshot:andQuit: 113811812 TheWorldMenu>saveAndQuit c) more reading directory information which takes us to 160ms, plugin lookup I'd guess d) Then copybits and an incremental gc (finally screen interaction lets look at the stack. 116380820 GrafPort>copyBits 116380680 GrafPort>fillRect:offset: 116380576 FormCanvas>frameAndFillRectangle:fillColor:borderWidth:borderColor: 116380484 Canvas>fillRectangle:color: 116380392 FormCanvas>fillRectangle:fillStyle: 116380080 Canvas>fillRectangle:fillStyle:borderStyle: 116379204 Morph>drawOn: 116379112 PasteUpMorph>drawOn: 116346488 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 116341060 Rectangle>allAreasOutsideList:startingAt:do: 116340968 Rectangle>allAreasOutsideList:do: 116346236 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 116340876 SequenceableCollection>do: 116344704 WorldState>drawWorld:submorphs:invalidAreasOn: 116344428 [] in WorldState>displayWorld:submorphs: 116339988 FormCanvas>roundCornersOf:in:during: 116339804 Canvas>roundCornersOf:during: 116338848 WorldState>displayWorld:submorphs: 116338756 PasteUpMorph>privateOuterDisplayWorld 116338664 PasteUpMorph>displayWorld 116338296 [] in WorldState>displayWorldSafely: 116338572 BlockContext>on:do: 116337784 BlockContext>ifError: 116337692 WorldState>displayWorldSafely: 116337600 PasteUpMorph>displayWorldSafely 116270492 PasteUpMorph>install 116270400 AutoStart class>checkForUpdates 116270308 AutoStart class>startUp: 114043140 [] in SystemDictionary>send:toClassesNamedIn:with: 114042916 OrderedCollection>do: 114042824 SystemDictionary>send:toClassesNamedIn:with: 114042732 SystemDictionary>processStartUpList: 113811996 SmalltalkImage>snapshot:andQuit:embedded: 113811904 SmalltalkImage>snapshot:andQuit: 113811812 TheWorldMenu>saveAndQuit e) more directory reading f) primitiveRenderScanLine is invoked, copybits, increment gcs 116366536 BalloonEngine>copyLoopFaster 116366444 BalloonEngine>copyBits 116366336 BalloonEngine>postFlushIfNeeded 116315708 BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 116315568 BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 116315464 BalloonCanvas>fillRectangle:fillStyle: 116315372 FormCanvas>balloonFillRectangle:fillStyle: 116315280 FormCanvas>fillRectangle:fillStyle: 116315096 Canvas>fillRectangle:fillStyle:borderStyle: 116311452 Morph>drawOn: 116311288 Canvas>draw: 116311184 Canvas>drawMorph: 116310356 [] in Morph>fullDrawOn: 116310908 CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 116310264 FormCanvas>roundCornersOf:in:during: 116310172 Canvas>roundCornersOf:during: 116308608 Morph>fullDrawOn: 116308516 Canvas>fullDraw: 116308424 Canvas>fullDrawMorph: 116297296 [] in Morph>drawSubmorphsOn: 116296520 SequenceableCollection>reverseDo: 116297020 [] in Morph>drawSubmorphsOn: 116296000 Morph>drawSubmorphsOn: 116294436 [] in Morph>fullDrawOn: 116294344 FormCanvas>roundCornersOf:in:during: 116294252 Canvas>roundCornersOf:during: 116290944 Morph>fullDrawOn: 116290840 Canvas>fullDraw: 116290428 Canvas>fullDrawMorph: 116292964 [] in Morph>drawSubmorphsOn: 116290336 SequenceableCollection>reverseDo: 116292688 [] in Morph>drawSubmorphsOn: 116289784 Morph>drawSubmorphsOn: 116284608 [] in Morph>fullDrawOn: 116285344 CornerRounder class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 116284516 FormCanvas>roundCornersOf:in:during: 116284424 Canvas>roundCornersOf:during: 116284292 Morph>fullDrawOn: 116284200 Canvas>fullDraw: 116284108 Canvas>fullDrawMorph: 116274292 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 116272416 Rectangle>allAreasOutsideList:startingAt:do: 116272324 Rectangle>allAreasOutsideList:do: 116274040 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 116272232 SequenceableCollection>do: 116272760 WorldState>drawWorld:submorphs:invalidAreasOn: 116272668 [] in WorldState>displayWorld:submorphs: 116272140 FormCanvas>roundCornersOf:in:during: 116272048 Canvas>roundCornersOf:during: 116271956 WorldState>displayWorld:submorphs: 116271864 PasteUpMorph>privateOuterDisplayWorld 116271772 PasteUpMorph>displayWorld 116271404 [] in WorldState>displayWorldSafely: 116271680 BlockContext>on:do: 116271312 BlockContext>ifError: 116271220 WorldState>displayWorldSafely: 116271128 PasteUpMorph>displayWorldSafely 116270124 PasteUpMorph>install 116270032 AutoStart class>checkForUpdates 116269940 AutoStart class>startUp: 114043140 [] in SystemDictionary>send:toClassesNamedIn:with: 114042916 OrderedCollection>do: 114042824 SystemDictionary>send:toClassesNamedIn:with: 114042732 SystemDictionary>processStartUpList: 113811996 SmalltalkImage>snapshot:andQuit:embedded: 113811904 SmalltalkImage>snapshot:andQuit: 113811812 TheWorldMenu>saveAndQuit g) 610ms elapsed time (say 450 ms of time doing (f)) before we finally attempt to flush the results to the hardware. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

[FIX] WatcherDoubleClickFix-nk
by ned＠squeakland.org 25 Feb '05

25 Feb '05

from preamble: "Change Set: WatcherDoubleClickFix-nk Date: 24 February 2005 Author: Ned Konz Double-clicking quickly on simple watcher just to the right of the number causes a walkback because the editor has already been deleted. I believe that this bug was introduced in CS 6566-0385muchBetterWatchers-sw. This change set fixes that problem. "!

1 0

Swiki back
by Ross Boylan 25 Feb '05

25 Feb '05

It seems to be accessible again. Apologies if this was already posted; my connectivity is intermittent. P.S. Still wondering: Isn't there a backup of the swiki somewhere?

1 0

[UPDATES] 11 more including m17n fixes
by Michael Rueger 25 Feb '05

25 Feb '05

Hi all, just pushed a few more plus a large change set by Yoshiki Ohshima and Takashi Yamamiya to make the image compatible to the Japanese version. Michael ----------------------- "Change Set: EvenMoreDepFixes-nk Date: 22 February 2005 Author: Ned Konz Fixes for several sends of known deprecated methods to known globals. " "Change Set: FileListRemoteDirectoryExceptionHandling-nk Date: 19 January 2005 Author: Ned Konz The FileList was showing a walkback on encountering protocol errors. This swallows these errors, showing a popup instead. In particular, this allows for 550 errors (no such directory) to be non-fatal; you just end up at the root. " "Change Set: FileListRenameFix-nk Date: 26 January 2005 Author: Ned Konz the FTP rename:toBe: error codes were wrong per RFC 640. This fixes them." "Change Set: FilePathAsString Date: 23 February 2005 Author: Andreas Raab Adds FilePath>>asString as alternative to FilePath>>asSqueakPathName" "Change Set: FixAnimatedGIFReading-nk Date: 22 February 2005 Author: Ned Konz Fixes reading of animated GIFs by removing an unintended shadowing of the 'offset' instance variable. " 6575fixLayoutFixes-nk "Change Set: ProcessSignalException Date: 23 February 2005 Author: Andreas Raab Change Process>>signal: anException to Process>>signalException: anException." "Change Set: ScriptEditorImageSegmentFix-nk Date: 22 Feb 2005 Author: Ned Konz Fixes a bug in ImageSegment where some ScriptEditorMorph instances could be incorrectly skipped because it was changing a collection it was iterating over. Changes invocations of 'isKindOf: Player' to use the pre-existing method #isPlayerLike. Changes invocations of 'isKindOf: EToyVocabulary' to use the new method #isEToyVocabulary. " "Change Set: socketFixes Date: 27 December 2004 Author: Michael Rueger, Avi Bryant, Masashi Umezawa Fixes the off-by-one in SocketStream>>upToAll: and adds some checks to the socket connection methods" 6579multilingual-Editor "Change Set: changesFromSql38ToJa Date: 23 February 2005 Author: Yoshiki Ohshima and Takashi Yamamiya Merge all the changes from Squeakland 3.8 388 to the latest working version of Japanese." -- impara GmbH Listemannstr. 10 39104 Magdeburg Germany Fon +49-391-598 0587 Fax +49-391-598 0581

2 1

modules-subscribe@discuss.squeakfoundation.org
by Cees de Groot 25 Feb '05

25 Feb '05

2 2

TTL/Lease expiry code somewhere?
by Cees de Groot 25 Feb '05

25 Feb '05

Hi, I wanted to hack another thing onto the p2p stuff, but got bogged down by something I really hope already exists, but I cannot seem to find :) What I'm working at is something called 'presence'. Users, files, and whatnot can all announce themselves 'present'. This is a lease, so if you don't regularly re-announce yourself present, your presence status will expire. We got this going on IRC when discussing possible enhancements to the p2p sample app (thanks Ken and Brian for testing) - you'd like to have a list of who is available for chat - but it seems like it would work for e.g. announcing the 'presence' of MC files as well. Now, the lease expiry thing is a bit of code that I hope is there, because it is more work outside the whole p2p business than I care to write :). Basically, what is needed is that if you report an object 'present', the object that manages local presence makes sure that when the TTL expires, the object is removed from the presence. When an existing object is reported present, the TTL should be reset (lease renewal). Etcetera. The idea is that each node collects presence information (which is two levels - for example 'CdG' would be declared present in 'ChatUsers', the latter will probably be replaced by a UUID and an external naming scheme but that's just some thoughts), and every X seconds swaps all changes in presence information with all its neighbours. In this way, presence information propagates reasonably quick without the need for individual broadcasts to announce presence over the network. Is there any lease management code floating around? Am I just missing a simple algorithm to do this? I'm extremely tired at the moment, so chances are that I'm overlooking something obvious, but any help here is appreciated :) TIA, Cees

1 0

RE: Improving Squeak's Multimedia - Part 2
by Bryce Kampjes 25 Feb '05

25 Feb '05

Russell Penney writes: > > I will make my feelings about plugins clear for the last time (cause no one > like a nagger :). I see plugins as a necessary evil. Yes they speed things > up but they ALSO reduce portability. I would love to see a "pure" smalltalk > implementation of all A/V classes with plugins used to speed up parts that > are required. That way the base is portable to any machine, it might not be > fast but it will work. Pure Smalltalk implementations are nice to have and we can make them faster as well. How hard depends on what basic data types are used. Just integers that fit into 31 bits? Not too bad. Floats and true 32 bit integers are harder. I'm interested in Multimedia but will not participate directly but feel free to point out interesting inner loops. Bryce P.S. Exupery is now only 10% slower than VisualWorks for the bytecode benchmark and sends are now faster than the interpreter.

1 0

Message-eating null?
by Cees de Groot 24 Feb '05

24 Feb '05

Hi, http://www.smalltalkchronicles.net/edition2-1/null_object_pattern.htm I got fed up with all the ifNil:.... tests in my domain code today, so based on my excellent experiences with using the 'message eating null' pattern in previous projects (with VW), I decided to add this thing to my toolkit. However, to my disappointment I found that #ifNil: and friends are optimized by the compiler, so there's no way to override them (they're compiled to '== nil' and a jump). Is there a way to circumvent this? It really is a very useful thing to have, it cleans up code in your domain layer tremendously. (the only solution I could think of is changing the compiler and recompiling the system. hardly attractive...)

1 0

re: read the traits papers (was "To Traits Or Not To Traits")
by Craig Latta 24 Feb '05

24 Feb '05

Hi-- Göran writes: > then we take first look, and then probably solicit some feedback from > stakeholders. Stéphane responds: > Yes please do it, but read the %$%$#$%#X papers... Göran responds: > Calm down Stephane - not all Squeakers have the time to read your > papers. I will read them - at least some of them - but don't expect > all of us to have the time to do that. This seems very odd to me. I just don't see the point of having this discussion without being informed. Reading the papers is work, yes, but it seems mandatory if one is to take the Traits work seriously (and less work than this email thread so far :). And how nice that there are papers to read! That's a pleasant luxury for us. Read the papers. :) Diligence demands it. -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org [|] Proceed for Truth!

3 2

RE: Stefs roadmap for 3.9, time to get it nailed down
by Peter Crowther 24 Feb '05

24 Feb '05

> From: [...] Lex Spoon > Martin Wirblat <sql.mawi(a)t-link.de> wrote: > > Here are Squeak's current problems ordered by importance: > > > > 1) library > > 2) speed > > 3) documentation > > 4) community organization > > 5) public relations and awareness > > 6) language > > Hmm, let me try. My list would be something like: > > 1. Stability, including stable sets of packages. > 2. Dicing up the shared image into packages. > 3. Documentation. > 4. Better interfaces to the platform, especially to windowing systems > 5. Beefing up the libraries in various ways. > 6. Language, namespaces, ... > 6. Public relations. Well, if we're into lists... This lot presupposes that our intention is to make a system that will scale to a larger number of developers, and will attract those developers. If those aren't the goals, this list isn't appropriate - note that it doesn't correspond to my own wish-list, for example. It's also a list of goals; assume a problem corresponding to each goal exists ;-). 1. Some way of stopping us all fighting over a single hunk of bits - the image as it is distributed. Call it packages, modules, sawdust, whatever. At present, this seems to be crippling development. 2. Sufficient speed and stability that the rest of this can be developed without the developers getting hacked off with their toolset. I develop in MVC on Squeak 2.2. It's really quick; I'd recommend a trip back in time to anyone using the Morphic tools in a recent image! 3. Sufficient (but not excessive) documentation on the core and the commonly-used packages so that an interested newcomer can pick this up and use it. This would include tutorial documentation, which is probably the hardest part to write as it doesn't necessarily correspond to the structure of the code. 4. Anything else. - Peter

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
43
Older →

Jump to page: