- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo apparently slow on linux

by Damien Cassou

2009/7/18 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Back to the topic at hand; let's see if I am following.Â Start with a core > image, run a script that installs what looks like a Pharo web image, makes a > few changes to settings in favor of speed, and you get something that you > find faster than Pharo??Â Did you make the same speed selections in Pharo? > If so, one wonders what happened between core and Pharo-dev/web that Lukas > did not do to the core image. The difference is OB-Enhancements. OB-Enhancements is currently installed in Pharo (not for long) but not in Lukas' script. OB-Enhancements brings a MC package browsing whearead Lukas' brings a Pharo category browsing. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 18, 2009

Re: [Pharo-project] Pharo apparently slow on linux

by Schwab,Wilhelm K

Laurent, I will preface this by saying that I have had a fairly intense week with Pharo. I am closing in on a solution to a real problem. I greatly miss Dolphin's Browse-it command, and its F12 and shift-F12 (definitions/references to a typed selector); the message search has its points, but it takes some extra steps to use in comparison to the Dolphin features. Back to the topic at hand; let's see if I am following. Start with a core image, run a script that installs what looks like a Pharo web image, makes a few changes to settings in favor of speed, and you get something that you find faster than Pharo?? Did you make the same speed selections in Pharo? If so, one wonders what happened between core and Pharo-dev/web that Lukas did not do to the core image. Sorry if I'm off base here - it's been a long and very good few days. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Saturday, July 18, 2009 12:45 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo apparently slow on linux On Fri, Jul 17, 2009 at 8:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Hi David shaffer reported to me in fuzzy way that pharo is slow on linux. Dear linux users can you report if you experienced the same and on which machine distributions vm image please compare the core and the dev (with browser usage) _______________________________________________ Hi, machine: core duo 2.0 GHz, 1 GB RAM (White Macbook, 2007) distribution: Archlinux vm: exupery pharo-vm-0.15.1b-linux.zip images: pharo0.1-10373dev09.07.2 and latest Pharo-Core Pharo-Core: (System Browser) - startup time: instantaneous - navigate randomly in browser: 3% - 8% CPU usage - find class OrderedCollection: ~10% CPU - browse senders of add: time to open 1s, 21% CPU Pharo-Dev: (Package Browser) - statup time: 3s (cold start 5s) - navigate randomly in browser: 9% - 15% CPU usage - find class OrderedCollection: ~13% CPU - browse senders of add: time to open 19s, 48% CPU Now I'm using Pharo-Core with Luka's scripts (http://code.google.com/p/pharo/wiki/ImageBuildScripts) as it's far more pleasant to use for me. Laurent

July 18, 2009

Re: [Pharo-project] Pharo apparently slow on linux

by laurent laffont

On Fri, Jul 17, 2009 at 8:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi > > David shaffer reported to me in fuzzy way that pharo is slow on linux. > Dear linux users can you report if you experienced the same and > on which > machine > distributions > vm > image > > please compare the core and the dev (with browser usage) > > _______________________________________________ > Hi, machine: core duo 2.0 GHz, 1 GB RAM (White Macbook, 2007) distribution: Archlinux vm: exupery pharo-vm-0.15.1b-linux.zip images: pharo0.1-10373dev09.07.2 and latest Pharo-Core Pharo-Core: (System Browser) - startup time: instantaneous - navigate randomly in browser: 3% - 8% CPU usage - find class OrderedCollection: ~10% CPU - browse senders of add: time to open 1s, 21% CPU Pharo-Dev: (Package Browser) - statup time: 3s (cold start 5s) - navigate randomly in browser: 9% - 15% CPU usage - find class OrderedCollection: ~13% CPU - browse senders of add: time to open 19s, 48% CPU Now I'm using Pharo-Core with Luka's scripts ( http://code.google.com/p/pharo/wiki/ImageBuildScripts) as it's far more pleasant to use for me. Laurent

July 18, 2009

[Pharo-project] Seaside for html generation

by Schwab,Wilhelm K

Hello all, I am loading a fair amount of code into Pharo, trying to get something working. SIF has worked well so far. The system in question will be Seaside based, but it will start life as a glorified spam generator :) Its operator will use some Seaside forms to tell the system about new data, edit the data to eliminate human errors, and then tell it to send emails based on the remaining data. The emails will be just complicated enough to benefit from html formatting. Yes, the users should be told only to visit the site to retrieve their electronic lashes via Seaside, but that will not happen over night - they haven't thought of it yet ;) The _real_ reason is that I still have to sort out the authentication mechanism. The dumb question: can I simply create a WACanvas, send some messages, and get the rendered html? Any ugly side effects of doing that? I ask because I have code for Dolphin that does the job, but it seems silly to load it into an image with Seaside. Bill

July 18, 2009

Re: [Pharo-project] MD5 in pharo?

by Schwab,Wilhelm K

Esteban, IMHO, the correct path is to write an interface for OpenSSL. Ultimately, that should also give us SSL sockets, but long before that, it can provide various hashes and cyphers with very little effort. I am open on whether the interface should be FFI, Alien, or plugin based. One argument for a plugin could come through benefits that _might_ acrue to sockets. I have along way to go on Squeak/Pharo external interfacing, so I could be way off here(!!), but I am under the impression that plugins can use OS threads, and that could greatly simplify getting OpenSSL to not hang the entire image while waiting on things to happen to/on a socket; that benefit would come at the cost of having to write a plugin. Another option might be to use FFI/Alien to access the cyphers and have a plugin for the SSL sockets. Hopefully someone with Squeak external interfacing experience will tell us "where be the dragons" with the various options. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban Lorenzano Sent: Friday, July 17, 2009 7:25 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] MD5 in pharo? Hi, Some time ago, I read a thread about cryotography, and as far as I remember, some body says about integrate the basic algoritms (MD5 and maybe others) as part of the pharo core. Well... now I need to use MD5 and cryptography package is not working well (it opens a debugger each time I save my image). I wonder if there are another package with MD5? Cheers, Esteban _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] KnownLands: a Class dependency explorer

by David Goehrig

On Fri, Jul 17, 2009 at 11:23 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > I will be interested in knowing what are the problem you're facing in > installing Mondrian. > I would too... every time I try to install on any of my images, it goes away for a long time, and never comes out of whatever process coma it has induced. My guess is that some change I made to one of my base classes ages ago has crippled some message send in a bizarre way. I'm not seeing any messages in the transcript, but I've occasionally received out of memory errors. As has been pointed out elsewhere, I tend to abuse my images something fierce, and have very little interest in maintaining baseline compatibility as they're primarily used to prototype language constructs for other projects. Since I don't use Squeak for production code, I tend to abuse it more than a fulltime Smalltalker would. :) Maybe I'll start from a known fresh image, install Mondrian, then attempt to load my stuff. -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 18, 2009

[Pharo-project] questions - class variable convention & Magritte arrays?

by Cameron Sanders

-- Three questions regarding implementing singletons: 1. the convention is to use an initial cap for class variable names, correct? (even though it is not required...) 2. Magritte will likely be used. And I have not dug too deeply. My current (temporary/stepping stone) class is Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'TheSingleton' poolDictionaries: '' category: 'FA-FinanceMeta' But I realized that I need even more information than (the basic) Magritte in some cases, and the "Fn" part of the name up above is really referring to financial series (multi-year data). The length of the series varies (depending on what is available). So the question is: does magritte have any capabilities (classes) for handling list display/edit as well as SQL access? Or is that something I will need to build? [And a "yes, read the manual, you idiot!" answer is helpful!] Thanks in advance, Cam

July 18, 2009

[Pharo-project] MD5 in pharo?

by Esteban Lorenzano

Hi, Some time ago, I read a thread about cryotography, and as far as I remember, some body says about integrate the basic algoritms (MD5 and maybe others) as part of the pharo core. Well... now I need to use MD5 and cryptography package is not working well (it opens a debugger each time I save my image). I wonder if there are another package with MD5? Cheers, Esteban

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by Cameron Sanders

In Pharo, I originally create created the class with this: Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'theSingleton' poolDictionaries: '' category: 'FA-FinanceMeta' And it compiled without complaint in Pharo. It was Squeak that complained during a load using Monticello. And just now, I reverted back to the lower case version (as exampled up above) and throws an "Error: theSingleton class variable name should be capitalized; proceed to include it anyway" ... and it lets me proceed. (I didn't read the full message previously and changed it.) So Squeak allows it, but complains where Pharo didn't. Sounds like it was "by design" in both cases. (I have three spinoff questions which I will put forth with a different subject line.) Thanks, Cam On Jul 17, 2009, at 6:04 PM, StÃ©phane Ducasse wrote: > this is strange can you show us the class definition. > > We removed the hard check that > enforced that classVariable should be capitalized and instvar starting > with a lower case. > > Lukas wrote some smallLint rules to check that > > Stef > > On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: > >> I just loaded the code I have been developing in Pharo into Squeak >> (closure VM, using 4.10.2-7179web09.07 image base) and it had one >> complaint while loading: >> >> Squeak (seemingly) requires an initial cap on class variable names. >> [Maybe it allows it... but it popped up the debugger on an MC load.] >> >> Does Pharo allow the symbol to start with lower case by design, or >> was >> that act of omission? I am merely raising point to make certain it is >> an act of commission. >> >> -Cam >>

July 18, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Schwab,Wilhelm K

Nicolas, Thanks for investigating this. As I said before, I suspect badness might follow any attempt to fork the extra work; once the user can do something with the image, they might do something that will race with the save/restart. A better way to go would be to get the vm to tell the image when it is loading and shutting down, and do some Dolphin-like thinking with session managers. It won't be trivial to do, but the current situation is inefficient. Even with things as-is, is there any danger to moving the Cursor normal show to the end of the re-start sequence? Should that help to make the duration of the save cursor more "honest?" I tried it briefly without much apparent success, but the machine in question takes a long time to save an image anyway. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Friday, July 17, 2009 3:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? As a follow-up 1) I asked the vm-dev list about opportunity to add a primFork() but it appears to be highly non portable (at least on windows) 2) I inquired what happens during a simple snapshot with this snippet (save, not quit) MessageTally spyOn: [ Object flushDependents. Object flushEvents. Smalltalk processShutDownList: false. Cursor write show. Smalltalk at: #ImageSegment ifPresent: [:theClass | theClass reclaimObsoleteSegmentFiles]. Cursor normal show. Smalltalk setGCParameters. Smalltalk processStartUpList: false.] And got these results: (highly variating...) - 1709 tallies, 1715 msec. **Tree** 51.9% {890ms} SystemDictionary>>processShutDownList: |51.9% {890ms} SystemDictionary>>send:toClassesNamedIn:with: | 51.9% {890ms} FileDirectory class(Behavior)>>shutDown: | 33.4% {573ms} FileDirectory class>>shutDown | |33.4% {573ms} SmalltalkImage>>closeSourceFiles | | 33.4% {573ms} MultiByteFileStream(StandardFileStream)>>close | | 33.4% {573ms} MultiByteFileStream(StandardFileStream)>>unregister | | 33.4% {573ms} MultiByteFileStream class(StandardFileStream class)>>unregister: | | 33.4% {573ms} WeakRegistry>>remove:ifAbsent: | | 33.4% {573ms} WeakIdentityKeyDictionary(Dictionary)>>removeKey:ifAbsent: | | 33.4% {573ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>fixCollisionsFrom: | | 33.4% {573ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>rehash | 14.3% {245ms} Form class>>shutDown | |12.7% {218ms} primitives | 4.2% {72ms} StrikeFont class>>shutDown | 4.2% {72ms} StrikeFont>>reset | 3.6% {62ms} StrikeFont>>name 40.8% {700ms} SystemDictionary>>processStartUpList: |40.8% {700ms} SystemDictionary>>send:toClassesNamedIn:with: | 40.8% {700ms} InputEventPollingFetcher class(Behavior)>>startUp: | 35.1% {602ms} InputEventPollingFetcher class(InputEventFetcher class)>>startUp | |35.1% {602ms} InputEventPollingFetcher(InputEventFetcher)>>startUp | | 35.1% {602ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop | | 35.1% {602ms} BlockClosure>>forkAt: | | 35.1% {602ms} Process>>resume | 3.7% {63ms} FileDirectory class>>startUp | 3.6% {62ms} SmalltalkImage>>openSourceFiles | 3.6% {62ms} FileDirectory class>>openSources:andChanges:forImage: | 2.9% {50ms} FileDirectory class>>openSources:forImage: | 2.0% {34ms} FileDirectory class>>openSources:forImage: 6.1% {105ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop 6.1% {105ms} InputEventPollingFetcher(InputEventFetcher)>>eventLoop 6.1% {105ms} InputEventPollingFetcher>>waitForInput 6.1% {105ms} Delay>>wait 6.1% {105ms} Delay>>unschedule **Leaves** 35.2% {604ms} Process>>resume 33.5% {575ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>rehash 12.7% {218ms} Form class>>shutDown 6.1% {105ms} Delay>>unschedule 3.6% {62ms} StrikeFont>>name **Memory** old -7,519,288 bytes young +5,575,572 bytes used -1,943,716 bytes free -203,436 bytes **GCs** full 1 totalling 578ms (34.0% uptime), avg 578.0ms incr 12 totalling 14ms (1.0% uptime), avg 1.0ms tenures 0 root table 0 overflows - 1117 tallies, 1120 msec. **Tree** 75.8% {849ms} SystemDictionary>>processShutDownList: |75.8% {849ms} SystemDictionary>>send:toClassesNamedIn:with: | 75.8% {849ms} FileDirectory class(Behavior)>>shutDown: | 48.9% {548ms} FileDirectory class>>shutDown | |48.9% {548ms} SmalltalkImage>>closeSourceFiles | | 48.9% {548ms} MultiByteFileStream(StandardFileStream)>>close | | 48.9% {548ms} MultiByteFileStream(StandardFileStream)>>unregister | | 48.9% {548ms} MultiByteFileStream class(StandardFileStream class)>>unregister: | | 48.7% {545ms} WeakRegistry>>remove:ifAbsent: | | 48.7% {545ms} WeakIdentityKeyDictionary(Dictionary)>>removeKey:ifAbsent: | | 48.7% {545ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>fixCollisionsFrom: | | 48.7% {545ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>rehash | 20.7% {232ms} Form class>>shutDown | |20.7% {232ms} Form>>hibernate | | 18.1% {203ms} ByteArray class(Behavior)>>new: | | 2.6% {29ms} primitives | 6.3% {71ms} StrikeFont class>>shutDown | 6.3% {71ms} StrikeFont>>reset | 5.9% {66ms} TextStyle class>>named: | 5.9% {66ms} Dictionary>>at:ifAbsent: | 5.9% {66ms} Dictionary(Set)>>findElementOrNil: | 5.9% {66ms} Dictionary>>scanFor: | 5.9% {66ms} ByteSymbol(Symbol)>>= 13.9% {156ms} SystemDictionary>>processStartUpList: |13.9% {156ms} SystemDictionary>>send:toClassesNamedIn:with: | 13.9% {156ms} InputEventPollingFetcher class(Behavior)>>startUp: | 4.6% {52ms} FileDirectory class>>startUp | |4.5% {50ms} SmalltalkImage>>openSourceFiles | | 4.4% {49ms} FileDirectory class>>openSources:andChanges:forImage: | | 3.3% {37ms} FileDirectory class>>openSources:forImage: | | 2.1% {24ms} FileDirectory class>>openSources:forImage: | 4.0% {45ms} InputEventPollingFetcher class(InputEventFetcher class)>>startUp | |4.0% {45ms} InputEventPollingFetcher(InputEventFetcher)>>startUp | | 4.0% {45ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop | | 4.0% {45ms} BlockClosure>>forkAt: | | 4.0% {45ms} Process>>resume | 3.3% {37ms} InputEventSensor class>>startUp | 3.3% {37ms} InputEventSensor class>>installKeyDecodeTable | 2.7% {30ms} Character>>isAlphaNumeric | 2.6% {29ms} Character>>isLetter | 2.5% {28ms} Latin1Environment class(LanguageEnvironment class)>>isLetter: | 2.5% {28ms} Unicode class>>isLetter: | 2.5% {28ms} SparseLargeTable>>at: | 2.5% {28ms} SparseLargeTable>>pvtCheckIndex: 8.5% {95ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop 8.5% {95ms} InputEventPollingFetcher(InputEventFetcher)>>eventLoop 8.5% {95ms} InputEventPollingFetcher>>waitForInput 8.5% {95ms} Delay>>wait 8.5% {95ms} Delay>>unschedule **Leaves** 48.8% {547ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>rehash 18.1% {203ms} ByteArray class(Behavior)>>new: 8.5% {95ms} Delay>>unschedule 6.2% {69ms} ByteSymbol(Symbol)>>= 4.2% {47ms} Process>>resume 2.6% {29ms} Form>>hibernate 2.5% {28ms} SparseLargeTable>>pvtCheckIndex: **Memory** old +5,931,864 bytes young -13,040 bytes used +5,918,824 bytes free +57,240 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 12 totalling 40ms (4.0% uptime), avg 3.0ms tenures 1 (avg 12 GCs/tenure) root table 0 overflows - 1451 tallies, 1456 msec. **Tree** 62.9% {916ms} SystemDictionary>>processShutDownList: |62.9% {916ms} SystemDictionary>>send:toClassesNamedIn:with: | 31.5% {459ms} StrikeFont class(Behavior)>>shutDown: | |13.9% {202ms} Form class>>shutDown | | |13.2% {192ms} primitives | |9.2% {134ms} StrikeFont class>>shutDown | | |9.2% {134ms} StrikeFont>>reset | | | 4.7% {68ms} TextStyle class>>named: | | | |4.7% {68ms} TextStyle(Object)>>isKindOf: | | | 4.3% {63ms} Array(Collection)>>detect:ifNone: | |8.5% {124ms} InputEventPollingFetcher class(InputEventFetcher class)>>shutDown | | 8.5% {124ms} InputEventPollingFetcher(InputEventFetcher)>>shutDown | | 8.5% {124ms} InputEventPollingFetcher>>terminateEventLoop | | 8.5% {124ms} InputEventPollingFetcher(InputEventFetcher)>>terminateEventLoop | | 8.5% {124ms} Process>>terminate | | 8.5% {124ms} Process>>popTo: | | 8.5% {124ms} Process>>return:value: | | 8.5% {124ms} Process>>complete: | | 8.5% {124ms} MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: | | 8.5% {124ms} ContextPart class>>contextOn:do: | 31.4% {457ms} BlockClosure>>on:do: 35.7% {520ms} SystemDictionary>>processStartUpList: 35.7% {520ms} SystemDictionary>>send:toClassesNamedIn:with: 35.7% {520ms} InputEventPollingFetcher class(Behavior)>>startUp: 29.9% {435ms} InputEventPollingFetcher class(InputEventFetcher class)>>startUp |29.9% {435ms} InputEventPollingFetcher(InputEventFetcher)>>startUp | 29.9% {435ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop | 29.9% {435ms} BlockClosure>>forkAt: | 29.9% {435ms} Process>>resume 3.6% {52ms} FileDirectory class>>startUp 3.5% {51ms} SmalltalkImage>>openSourceFiles 3.4% {50ms} FileDirectory class>>openSources:andChanges:forImage: 2.5% {36ms} FileDirectory class>>openSources:forImage: **Leaves** 31.4% {457ms} BlockClosure>>on:do: 30.0% {437ms} Process>>resume 13.2% {192ms} Form class>>shutDown 8.5% {124ms} ContextPart class>>contextOn:do: 4.7% {68ms} TextStyle(Object)>>isKindOf: 4.3% {63ms} Array(Collection)>>detect:ifNone: **Memory** old -146,072 bytes young -406,232 bytes used -552,304 bytes free +406,132 bytes **GCs** full 1 totalling 392ms (27.0% uptime), avg 392.0ms incr 12 totalling 13ms (1.0% uptime), avg 1.0ms tenures 0 root table 0 overflows - 1877 tallies, 1882 msec. **Tree** 49.4% {930ms} SystemDictionary>>processStartUpList: |49.4% {930ms} SystemDictionary>>send:toClassesNamedIn:with: | 49.4% {930ms} InputEventPollingFetcher class(Behavior)>>startUp: | 44.9% {845ms} InputEventPollingFetcher class(InputEventFetcher class)>>startUp | |44.9% {845ms} InputEventPollingFetcher(InputEventFetcher)>>startUp | | 44.9% {845ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop | | 44.9% {845ms} BlockClosure>>forkAt: | | 44.9% {845ms} Process>>resume | 2.7% {51ms} FileDirectory class>>startUp | 2.7% {51ms} SmalltalkImage>>openSourceFiles | 2.6% {49ms} FileDirectory class>>openSources:andChanges:forImage: 45.9% {864ms} SystemDictionary>>processShutDownList: |45.9% {864ms} SystemDictionary>>send:toClassesNamedIn:with: | 45.9% {864ms} ExternalSettings class(Behavior)>>shutDown: | 24.5% {461ms} ExternalSettings class>>shutDown | |24.5% {461ms} ServerDirectory class>>releaseExternalSettings | | 24.5% {461ms} Preferences class>>doesNotUnderstand: | | 24.5% {461ms} Preferences class>>valueOfFlag: | | 24.5% {461ms} Preferences class>>valueOfPreference:ifAbsent: | | 24.5% {461ms} Preferences class>>preferenceAt:ifAbsent: | | 24.5% {461ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | 24.5% {461ms} IdentityDictionary(Set)>>findElementOrNil: | | 24.5% {461ms} IdentityDictionary>>scanFor: | 17.8% {335ms} StrikeFont class>>shutDown | |10.7% {201ms} StrikeFontSet class(Behavior)>>allSubInstancesDo: | | |10.7% {201ms} StrikeFontSet class(Behavior)>>allInstancesDo: | |7.1% {134ms} StrikeFont>>reset | | 3.7% {70ms} StrikeFont>>familyName | | |3.7% {70ms} ByteString(String)>>withoutTrailingDigits | | | 3.7% {70ms} Character>>isDigit | | | 3.7% {70ms} Latin1Environment class(LanguageEnvironment class)>>isDigit: | | 3.2% {60ms} ByteString(SequenceableCollection)>>, | | 3.2% {60ms} ByteString(SequenceableCollection)>>copyReplaceFrom:to:with: | | 3.2% {60ms} ByteString(Object)>>species | 3.6% {68ms} Form class>>shutDown | 3.6% {68ms} Form class(Behavior)>>allInstancesDo: 3.7% {70ms} InputEventPollingFetcher(InputEventFetcher)>>installEventLoop 3.7% {70ms} InputEventPollingFetcher(InputEventFetcher)>>eventLoop 3.7% {70ms} InputEventPollingFetcher>>waitForInput 3.7% {70ms} Delay>>wait 3.7% {70ms} Delay>>unschedule **Leaves** 44.9% {845ms} Process>>resume 24.5% {461ms} IdentityDictionary>>scanFor: 14.3% {269ms} StrikeFontSet class(Behavior)>>allInstancesDo: 3.7% {70ms} Latin1Environment class(LanguageEnvironment class)>>isDigit: 3.7% {70ms} Delay>>unschedule 3.2% {60ms} ByteString(Object)>>species **Memory** old -13,012,128 bytes young +5,635,236 bytes used -7,376,892 bytes free -822,368 bytes **GCs** full 1 totalling 800ms (43.0% uptime), avg 800.0ms incr 12 totalling 11ms (1.0% uptime), avg 1.0ms tenures 1 (avg 12 GCs/tenure) root table 0 overflows 2009/7/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Current policy is to cleanup before saving, and reconnect after saving > as if a fresh startup occured As you seem to suggest, a possible > alternative without using fork would be to: > 1) distinguish whether this is a newly restarted image (primSnapshot > returning true or false...) > 2) perform all the clean-ups at startup if newly restarted image > 3) rely on the process exit() to perform required resource clean-up in > case we quit (or let a self aboutToQuit do some) > > Step 2) would deserve great care, any unprotected access to an > uninitialized pointer of the old image would crash or trash memory... > > Nicolas > > 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Nicolas, >> >> One thing I forgot to mention: thread safety??? IIRC, Dolphin triggers startup events, and all external resources clear pointers then (though they will release on shutdown, not image saving) to force a lazy connection. >> >> I see why, absent help from the vm, the image does not know when it starts and stops. What I do not get is why the vm does not tell it. If it did, I _think_ we could clean all of this up. Sometimes the truth hurts though, so please find any faults in my logic (or lack thereof). >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Nicolas Cellier >> Sent: Thursday, July 16, 2009 3:11 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? >> >> Yes, it would require a small vm change to fork. >> To be more accurate here's a simplified draft of my proposition: >> The fork has one bit different, so let it be a prilmitive returning true or false: >> >> primFork >> "return true if we are in the forked image, false in the original" >> >> <primitive: XXX> >> >> snapshot >> self primFork ifTrue: [ >> self aboutToSnapshot. >> self primSaveAndQuit. >> self returnFromSnapshot]. >> >> Nicolas >> >> 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Nicolas, >>> >>> I'm all for doing this better, and have watched for a while as (it appears to me at least) Squeak got ever closer to having formal startup and shutdown code. However, the idea that Squeak "just runs" persists, perhaps for the good. It strikes me that we can do better, but it would require image and vm changes. >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >>> Nicolas Cellier >>> Sent: Thursday, July 16, 2009 2:10 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? >>> >>> Does that really has to be so ? >>> An alternative would be to clone the process (fork) and do a snapshotAndQuit in the clone. >>> >>> Nicolas >>> >>> 2009/7/16 Lukas Renggli <renggli(a)gmail.com>: >>>>> These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. >>>> >>>> It is correct that these scripts are run after a snapshot, because >>>> when the image is saved it has to be shutdown so that it can come >>>> up correctly again. I guess Dolphin works exactly the same. The >>>> problem in Pharo/Squeak is that some of shutdown and startup >>>> scripts might not really be necessary to run in the case of a save >>>> without quit, so feel free to submit optimizations in this area. >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009