July 2009 - Pharo-dev - lists.pharo.org

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

by Schwab,Wilhelm K

It would be one good idea among many in a very well engineered system. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Thursday, July 16, 2009 9:07 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? Indeed, that sounds like a good solution. 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > My recollection is that most of Dolphin's startup is forced to happen lazily as part of startup, allowing an image to both continue and start from the saved state. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Lukas Renggli > Sent: Thursday, July 16, 2009 8:27 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > >>Â 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 > -- 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

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:44 PM, Esteban Lorenzano wrote: > I use them a lot... just because "select:thenCollect:" looks clearer > to > me than "(select:)collect:", and I can indent the code in a more > fashion way to me. > Of course, if you choose remove it, I can change my code without any > problem (it is not so hard, after all :) ), but I just wanted to point > that optimization is not always the reason because a protocol can be > added... some times, is gramatics too. indeed but then it would be good to have it efficient also > > Cheers, > Esteban > > On 2009-07-16 07:02:56 -0300, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> said: > >> I'd favor removing such methods. The allocation optimization can be >> >> implemented better whenever it's needed, and IME it doesn't happen >> that >> >> often. >> >> StÃ©phane Ducasse wrote: >>> so in that case I would be in favor to remove them because this >>> does not help and just bloat the image. >>> >>> >>> >>> On Jul 16, 2009, at 8:21 AM, Lukas Renggli wrote: >>> >>> >> >>>>> select: selectBlock thenCollect: collectBlock >>>>> >>>>> | newCollection | >>>>> newCollection := self species new. >>>>> self do: [:each | (selectBlock value: each) ifTrue: >> >>>>> [newCollection add: >>>>> (collectBlock value: each)]]. >>>>> ^newCollection >>>>> >> >>>> That code would also break Dictionary and Array. >>>> >>>> I think the methods #select:thenCollect: and #collect:thenSelect: >>>> should be removed: >>>> >>>> - This is a low level optimization that the compiler (or JIT) >>>> should >>>> optimize, not the developer. >>>> - 'a select: b thenCollect: c' is longer to write than '(a >>>> select: b) >>>> collect: c'. Furthermore it is not that obvious what it does. I >>>> have >>>> seen several people being confused about it. >>>> - This is just #select:thenCollect:, what about >>>> #reject:thenCollect:select:thenInjectInto:? What about all >>>> subclasses >>>> that require a new implementation (Array, Dictionary, ...) of such >>>> methods. >>>> >>>> If people really want to be able to combine enumerator methods for >>>> higher efficiently the Collection hierarchy should be fixed. Having >>>> external iterator objects like in C++ and Java is not that bad >>>> after >>>> all: >>>> >>>> result := aCollection iterator >>>> select: [ :e | ... ]; >>>> collect: [ :e | ... ]; >>>> contents >>>> >>>> The accessors #select:, #reject:, #collect: ... on the iterator >>>> object >>>> would just iteratively create a new iteration block that is lazily >>>> executed when the result is accessed with #contents, #size or #do:. >>>> >>>> Cheers, >>>> 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

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:16 PM, Paolo Bonzini wrote: > On 07/16/2009 11:38 AM, StÃ©phane Ducasse wrote: >> Paolo >> >> why Iterable as a superclass of stream and collection? >> Why not a trait? >> Then I'm wondering why this would be faster. > > Maybe for just "(a select: ...) collect: b" it would not be faster. > > However, the important thing is to provide: > > 1) a new abstraction. Providing more polymorphism between Collections > and Streams can only do good, especially when the semantics are 100% > identical as for #detect: or #fold: (based on #do:). In GNU > Smalltalk I > did a bit more by providing also #readStream and #nextPutAllOn:, but > that's not necessary so I kept my pharo proposal minimal. > > 2) a new bag of tools. Lazy filtering has been proposed in many > different ways, so it *is* useful. Adding Iterable is in my opinion > the > best way to provide this tool in a way that fits the simplicity of the > standard Smalltalk class library (this is a way to say that > #doesNotUnderstand: tricks have their place, but other ways should be > explored as well). sure but for me my point was collect:thenSelect: looks badly implemented. Now you can that composed Stream. Damien has that in Nile since two years too. > > Paolo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 2:09 PM, Paolo Bonzini wrote: > On 07/16/2009 12:04 PM, Lukas Renggli wrote: >> I believe, that in >> this case*not* using traits forces you to do the right thing: >> delegate to another object that knows how to iterate over your >> object. > > Agreed. Adding a #do: method to a class can often be the right thing, > but I still have to see one case when a non-Collection, non-Stream > class > would have advantages from a public #inject:into: or #fold: or > #detect: > method. A sidenote -- things that do not count: In the moose environemnt we have group and they cannot inherit from Iterable. > 1) #select:/#reject:/#collect:, because those would be abstract in > Iterable anyway. > > 2) using the above methods from within the class itself, because > 99.99% > of the cases you will have an underlying collection or stream and you > can access that underlying object without violating information > hiding. yes so what? How this stream based iomplementation goes faster that the default collection one? > >>>>>> Is this going >>>>>> to be ANSI? >>>> >>>> DNU? why ANSI has to be in the story? >> >> Paolo is in the ANSI committee, I though. Maybe that will be added? > > There is no ANSI committee, that required to pay money and was not > considered viable. > > There is a mailing list (run by Bruce Badger) and a protocol (hosted > at > the GNU Smalltalk site, see the "STEPs" link in the home page) to > submit > proposals for extensions to Smalltalk, hopefully so that they can be > implemented cross vendor. But it has been dormient for too long. :-( > > Paolo > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

On Jul 16, 2009, at 12:04 PM, Lukas Renggli wrote: >>> Having an iterator class also avoids having to implement all these >>> iteration methods over and over again, e.g. in visitors. >> >> lukas do you have an example because I do not see why >> Also with traits you just have to implement do: and you get all the >> other one for free. > > The class and metaclass system of Smalltalk is already at the limit of > complexity that I can handle. Traits make this existing model even > more complicated. Even with support from a trait aware browser I find > traits extermely hard to use. To me the most important thing is that > at all points in time I know exactly what changes when I compile a > method. This is absolutely not clear when using traits. I find your statements a bit rude. > > So far I haven't seen a single example where traits would really help. Really! I'm writing a trait to get magritte-aware xml output without having to always inherit from a top class or to copy and paste all the time the same code in my classes. > As Paolo suggested the problem can be simply solved by introducing an > Iterable superclass to Collection and Stream. I do not see how his solution will offer a faster implementation > Now you might say that this only works if I am not inheriting from > some other important class. True, an Iterable-trait would avoid that > problem. However, adding such a trait to an existing hierarchy looks > extremely scary to me. It potentially pollutes an existing protocol > with existing code that is most likely unrelated (or maybe it already > contains some iterator code for something else). like what collect: select: do: reject: inject:into: ? I think that you should also have a look at what other people are doing. > I believe, that in > this case *not* using traits forces you to do the right thing: > delegate to another object that knows how to iterate over your object. > >>> Is this going >>> to be ANSI? >> >> DNU? why ANSI has to be in the story? > > Paolo is in the ANSI committee, I though. Maybe that will be added? ANSI is dead. It was a bunch of specification pushed apart because smalltalk was hot and vendors wanted or not a feature in.

July 16, 2009

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

by Lukas Renggli

Indeed, that sounds like a good solution. 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > My recollection is that most of Dolphin's startup is forced to happen lazily as part of startup, allowing an image to both continue and start from the saved state. > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli > Sent: Thursday, July 16, 2009 8:27 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > >>Â 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 > -- Lukas Renggli http://www.lukas-renggli.ch

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Mariano Martinez Peck

Pentium 4 2.26 GZ, windows XP SP3, 2GB RAM 168199737 bytecodes/sec; 3670275 sends/sec 2009/7/16 Benoit St-Jean <bstjean(a)yahoo.com> > If that helps... > > 0 tinyBenchmarks > > Windows XP, 2002, SP3 > Pentium 4, dual core, 3Ghz, 2 Gb RAM > > All tests were run 5 times and here are the averages : > > Some comparisons: > > Squeak 3.9 latest update: #7067 > 76297334 bytecodes/sec; 3397437 sends/sec > > Squeak 3.10.2 latest update: #7179 > 74839234 bytecodes/sec; 3443964 sends/sec > > Pharo 0.1 latest update: #10377 > 75877223 bytecodes/sec; 3134820 sends/sec > > > > > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > Blog: lamneth.wordpress.com > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ------------------------------ > *From:* Gary Chambers <gazzaguru2(a)btinternet.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Thursday, July 16, 2009 6:51:59 AM > > *Subject:* Re: [Pharo-project] Making some progress, and a few > observations > > In the Windows camp, Watery2 theme... > > Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), > Pharo0.1Core-10371. > > 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 373 > > Older laptop, XP, 1GB, Pentium M (1.73 GHz)... > > 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 677 > > Still feels quite responsive even on that! > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> > Sent: Thursday, July 16, 2009 2:07 AM > Subject: Re: [Pharo-project] Making some progress, and a few observations > > > On my crusty old Linux box: > > 155339805 bytecodes/sec; 3931964 sends/sec > > However, I always like to test on less than my customers will have, so by > some arguments, this machine is just about right. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain Plantec > [alain.plantec(a)free.fr] > Sent: Wednesday, July 15, 2009 6:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Making some progress, and a few observations > > Adrian Lienhard a Ã©crit : > > Bill, > > > > Could you post the results of the following benchmark? > > > > 0 tinyBenchmarks > > > > > On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: > > > > '543236074 bytecodes/sec; 12101592 sends/sec' > > > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit > pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' > pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' > > not so bad with linux :) > > Cheers > Alain > > > Cheers, > > Adrian > > > > On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: > > > > > >> Stef, > >> > >> No browser should be that slow. I suspect the Linux vm is not a > >> speed demon, the xp machines I use are heavily burdened by anit- > >> virus software and other performance drains, etc. My linux box at > >> home might be further hindered by the fact that I bought a wide > >> screen monitor for it, and use LOTS of screen real estate. Still, > >> when I compare Pharo with other software (including Dolphin) under > >> similarly abusive conditions, Pharo is not quick. > >> > >> This particular image is small; it is based on the most recent web > >> image, and is 22 MB. It has some of my Seaside code in it, but has > >> not yet executed same. I have a couple of Seaside cleanup > >> expressions that help when images bloat up, but looking at the > >> current size makes me think I'm missing an opportunity. All that > >> aside, on my linux box, I find that after the saving cursor > >> disappears, it can take a few seconds for the image to again become > >> responsive. On xp in my office, there is at least a second of down > >> time after the cursor reverts to normal. > >> > >> In doing some SIF imports, I noted that it was hard to tell when the > >> image was still busy. I have no idea how long it should take to do > >> the work it was doing, but it took long enough that some gentle > >> prodding becomes irresistable: "is it done yet?" I remember lots of > >> debate about Cursor class>>showWhile: on Dolphin; it might be one of > >> those things that is tricky to get right. > >> > >> A little bit nicer news: I have it running on my office machine > >> (xp), with FreeType in use, and it's ok with the standard tools and > >> the w2k theme. > >> > >> Bill > >> > >> > >> > >> -----Original Message----- > >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >> ] On Behalf Of StÃ©phane Ducasse > >> Sent: Wednesday, July 15, 2009 2:31 PM > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] Making some progress, and a few > >> observations > >> > >> > >>> Stef, > >>> > >>> In terms of response times, even with a lot of things turned off, I > >>> was still surprised at how long it takes to change from even one > >>> method to another. > >>> > >> which browser are you using. > >> Because the old browser should not be that slow. > >> > >> > >> > >>> Anything past 0.2 sec (or whatever that threshold is) starts to add > >>> up; Pharo sometimes takes up to a second, which is _really_ shows up. > >>> > >>> Saving an image is not necessarily quick either, I _think_ > >>> particuarly > >>> on Linux?? > >>> > >> What is the size of your image: here jannik generated an image of > >> 800 mb. > >> > >> > >>> Also, I get the sense the wait cursors are displayed, on Linux, for a > >>> smaller fraction of the down time than on Windows. > >>> > >>> Bill > >>> > >>> > >>> -----Original Message----- > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >>> ] On Behalf Of StÃ©phane Ducasse > >>> Sent: Wednesday, July 15, 2009 12:58 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-project] Making some progress, and a few > >>> observations > >>> > >>> > >>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: > >>> > >>> > >>>> Hello all, > >>>> > >>>> I managed to create an install script; as I suspected would be case, > >>>> it was very anticlimactic. I tried creating a password-protected > >>>> directory under my personal web site, but that did not go well. The > >>>> authentication is weird, so it was probably asking a lot. A > >>>> directory repository worked. > >>>> > >>> Good to know > >>> > >>>> Does Monticello/PackageInfo see a change in method category (aka > >>>> package) as a change to the package? > >>>> > >>> normally it should. > >>> > >>> > >>>> It appears not, and it worries me a little in that it seems to make > >>>> it easy to lose work by forgetting to save it. Do any of you script > >>>> saving your packages? > >>>> > >>> you can check in ScriptLoader to see how we compute the packages that > >>> changed (not only dirty but also new packages) > >>> > >>> > >>>> The results are untested at present, but I used SIF to transfer a > >>>> fair amount of code into Pharo. To cope with the naming of the ODBC > >>>> classes, I ended up doing things like Smalltalk at:#DBConnection > >>>> put:ODBCConnection, and that worked out nicely, at least AFAICT at > >>>> this stage. SIF finally ended up complaining about running out of > >>>> items when processing the last file. I reserve the right to later > >>>> report that it was a miserable failure, but it looks like I most of > >>>> the code imported. > >>>> > >>>> Using the standard tools, the w2k theme, disabling faded backgrounds > >>>> and enabling fast drag, performance on an older Linux system is ok > >>>> (more or less). There are still things that take too long, > >>>> > >>> like what? > >>> > >>> > >>>> and Pharo's responses are no better (sometimes worse) than even > >>>> software running over a remote desktop connection. We need a speed > >>>> boost, but judicious settings help a little. > >>>> > >>>> Is there a way to disable the anti-aliased fonts? In fairness, I > >>>> should try turning that off to see if any speed boost is worth the > >>>> price. > >>>> > >>>> Bill > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > > > > > > _______________________________________________ > 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 > > ------------------------------ > Make your browsing faster, safer, and easier with the new Internet > ExplorerÂ® 8. Optimized for Yahoo! *Get it Now for Free! *<http://downloads.yahoo.com/ca/internetexplorer/> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Benoit St-Jean

If that helps... 0 tinyBenchmarks Windows XP, 2002, SP3 Pentium 4, dual core, 3Ghz, 2 Gb RAM All tests were run 5 times and here are the averages : Some comparisons: Squeak 3.9 latest update: #7067 76297334 bytecodes/sec; 3397437 sends/sec Squeak 3.10.2 latest update: #7179 74839234 bytecodes/sec; 3443964 sends/sec Pharo 0.1 latest update: #10377 75877223 bytecodes/sec; 3134820 sends/sec ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Gary Chambers <gazzaguru2(a)btinternet.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, July 16, 2009 6:51:59 AM Subject: Re: [Pharo-project] Making some progress, and a few observations In the Windows camp, Watery2 theme... Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371. 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373 Older laptop, XP, 1GB, Pentium M (1.73 GHz)... 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677 Still feels quite responsive even on that! Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations On my crusty old Linux box: 155339805 bytecodes/sec; 3931964 sends/sec However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec(a)free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a Ã©crit : > Bill, > > Could you post the results of the following benchmark? > > 0 tinyBenchmarks > > On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: > > '543236074 bytecodes/sec; 12101592 sends/sec' > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain > Cheers, > Adrian > > On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: > > >> Stef, >> >> No browser should be that slow. I suspect the Linux vm is not a >> speed demon, the xp machines I use are heavily burdened by anit- >> virus software and other performance drains, etc. My linux box at >> home might be further hindered by the fact that I bought a wide >> screen monitor for it, and use LOTS of screen real estate. Still, >> when I compare Pharo with other software (including Dolphin) under >> similarly abusive conditions, Pharo is not quick. >> >> This particular image is small; it is based on the most recent web >> image, and is 22 MB. It has some of my Seaside code in it, but has >> not yet executed same. I have a couple of Seaside cleanup >> expressions that help when images bloat up, but looking at the >> current size makes me think I'm missing an opportunity. All that >> aside, on my linux box, I find that after the saving cursor >> disappears, it can take a few seconds for the image to again become >> responsive. On xp in my office, there is at least a second of down >> time after the cursor reverts to normal. >> >> In doing some SIF imports, I noted that it was hard to tell when the >> image was still busy. I have no idea how long it should take to do >> the work it was doing, but it took long enough that some gentle >> prodding becomes irresistable: "is it done yet?" I remember lots of >> debate about Cursor class>>showWhile: on Dolphin; it might be one of >> those things that is tricky to get right. >> >> A little bit nicer news: I have it running on my office machine >> (xp), with FreeType in use, and it's ok with the standard tools and >> the w2k theme. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Wednesday, July 15, 2009 2:31 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Making some progress, and a few >> observations >> >> >>> Stef, >>> >>> In terms of response times, even with a lot of things turned off, I >>> was still surprised at how long it takes to change from even one >>> method to another. >>> >> which browser are you using. >> Because the old browser should not be that slow. >> >> >> >>> Anything past 0.2 sec (or whatever that threshold is) starts to add >>> up; Pharo sometimes takes up to a second, which is _really_ shows up. >>> >>> Saving an image is not necessarily quick either, I _think_ >>> particuarly >>> on Linux?? >>> >> What is the size of your image: here jannik generated an image of >> 800 mb. >> >> >>> Also, I get the sense the wait cursors are displayed, on Linux, for a >>> smaller fraction of the down time than on Windows. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of StÃ©phane Ducasse >>> Sent: Wednesday, July 15, 2009 12:58 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Making some progress, and a few >>> observations >>> >>> >>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: >>> >>> >>>> Hello all, >>>> >>>> I managed to create an install script; as I suspected would be case, >>>> it was very anticlimactic. I tried creating a password-protected >>>> directory under my personal web site, but that did not go well. The >>>> authentication is weird, so it was probably asking a lot. A >>>> directory repository worked. >>>> >>> Good to know >>> >>>> Does Monticello/PackageInfo see a change in method category (aka >>>> package) as a change to the package? >>>> >>> normally it should. >>> >>> >>>> It appears not, and it worries me a little in that it seems to make >>>> it easy to lose work by forgetting to save it. Do any of you script >>>> saving your packages? >>>> >>> you can check in ScriptLoader to see how we compute the packages that >>> changed (not only dirty but also new packages) >>> >>> >>>> The results are untested at present, but I used SIF to transfer a >>>> fair amount of code into Pharo. To cope with the naming of the ODBC >>>> classes, I ended up doing things like Smalltalk at:#DBConnection >>>> put:ODBCConnection, and that worked out nicely, at least AFAICT at >>>> this stage. SIF finally ended up complaining about running out of >>>> items when processing the last file. I reserve the right to later >>>> report that it was a miserable failure, but it looks like I most of >>>> the code imported. >>>> >>>> Using the standard tools, the w2k theme, disabling faded backgrounds >>>> and enabling fast drag, performance on an older Linux system is ok >>>> (more or less). There are still things that take too long, >>>> >>> like what? >>> >>> >>>> and Pharo's responses are no better (sometimes worse) than even >>>> software running over a remote desktop connection. We need a speed >>>> boost, but judicious settings help a little. >>>> >>>> Is there a way to disable the anti-aliased fonts? In fairness, I >>>> should try turning that off to see if any speed boost is worth the >>>> price. >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ 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 __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

July 16, 2009

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

by Schwab,Wilhelm K

My recollection is that most of Dolphin's startup is forced to happen lazily as part of startup, allowing an image to both continue and start from the saved state. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Thursday, July 16, 2009 8:27 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? >Â 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

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Schwab,Wilhelm K

Stef, Thanks for looking at it that way. I would not bother you with this box if it were hopelessly slow. One common thing that keeps me using it is going on as I type: I'm using a remote desktop client to access a an xp machine in my office, and this broken down old plug does this better than it handles editing in Pharo. We have some room for improvement, and this box is available for benchamarking as needed. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, July 16, 2009 4:27 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Sounds like your machine is 4 times slower than ours. which is good we should all have machine like that to make pharo fast On Jul 16, 2009, at 3:07 AM, Schwab,Wilhelm K wrote: > On my crusty old Linux box: > > 155339805 bytecodes/sec; 3931964 sends/sec > > However, I always like to test on less than my customers will have, so > by some arguments, this machine is just about right. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Alain Plantec [alain.plantec(a)free.fr] > Sent: Wednesday, July 15, 2009 6:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Making some progress, and a few > observations > > Adrian Lienhard a Ã©crit : >> Bill, >> >> Could you post the results of the following benchmark? >> >> 0 tinyBenchmarks >> > >> On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: >> >> '543236074 bytecodes/sec; 12101592 sends/sec' >> > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit > pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' > pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' > > not so bad with linux :) > > Cheers > Alain > >> Cheers, >> Adrian >> >> On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: >> >> >>> Stef, >>> >>> No browser should be that slow. I suspect the Linux vm is not a >>> speed demon, the xp machines I use are heavily burdened by anit- >>> virus software and other performance drains, etc. My linux box at >>> home might be further hindered by the fact that I bought a wide >>> screen monitor for it, and use LOTS of screen real estate. Still, >>> when I compare Pharo with other software (including Dolphin) under >>> similarly abusive conditions, Pharo is not quick. >>> >>> This particular image is small; it is based on the most recent web >>> image, and is 22 MB. It has some of my Seaside code in it, but has >>> not yet executed same. I have a couple of Seaside cleanup >>> expressions that help when images bloat up, but looking at the >>> current size makes me think I'm missing an opportunity. All that >>> aside, on my linux box, I find that after the saving cursor >>> disappears, it can take a few seconds for the image to again become >>> responsive. On xp in my office, there is at least a second of down >>> time after the cursor reverts to normal. >>> >>> In doing some SIF imports, I noted that it was hard to tell when the >>> image was still busy. I have no idea how long it should take to do >>> the work it was doing, but it took long enough that some gentle >>> prodding becomes irresistable: "is it done yet?" I remember lots of >>> debate about Cursor class>>showWhile: on Dolphin; it might be one of >>> those things that is tricky to get right. >>> >>> A little bit nicer news: I have it running on my office machine >>> (xp), with FreeType in use, and it's ok with the standard tools and >>> the w2k theme. >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of StÃ©phane Ducasse >>> Sent: Wednesday, July 15, 2009 2:31 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Making some progress, and a few >>> observations >>> >>> >>>> Stef, >>>> >>>> In terms of response times, even with a lot of things turned off, I >>>> was still surprised at how long it takes to change from even one >>>> method to another. >>>> >>> which browser are you using. >>> Because the old browser should not be that slow. >>> >>> >>> >>>> Anything past 0.2 sec (or whatever that threshold is) starts to add >>>> up; Pharo sometimes takes up to a second, which is _really_ shows >>>> up. >>>> >>>> Saving an image is not necessarily quick either, I _think_ >>>> particuarly on Linux?? >>>> >>> What is the size of your image: here jannik generated an image of >>> 800 mb. >>> >>> >>>> Also, I get the sense the wait cursors are displayed, on Linux, for >>>> a smaller fraction of the down time than on Windows. >>>> >>>> Bill >>>> >>>> >>>> -----Original Message----- >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>>> ] On Behalf Of StÃ©phane Ducasse >>>> Sent: Wednesday, July 15, 2009 12:58 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Making some progress, and a few >>>> observations >>>> >>>> >>>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: >>>> >>>> >>>>> Hello all, >>>>> >>>>> I managed to create an install script; as I suspected would be >>>>> case, it was very anticlimactic. I tried creating a >>>>> password-protected >>>>> directory under my personal web site, but that did not go well. >>>>> The >>>>> authentication is weird, so it was probably asking a lot. A >>>>> directory repository worked. >>>>> >>>> Good to know >>>> >>>>> Does Monticello/PackageInfo see a change in method category (aka >>>>> package) as a change to the package? >>>>> >>>> normally it should. >>>> >>>> >>>>> It appears not, and it worries me a little in that it seems to >>>>> make it easy to lose work by forgetting to save it. Do any of you >>>>> script saving your packages? >>>>> >>>> you can check in ScriptLoader to see how we compute the packages >>>> that changed (not only dirty but also new packages) >>>> >>>> >>>>> The results are untested at present, but I used SIF to transfer a >>>>> fair amount of code into Pharo. To cope with the naming of the >>>>> ODBC classes, I ended up doing things like Smalltalk >>>>> at:#DBConnection put:ODBCConnection, and that worked out nicely, >>>>> at least AFAICT at this stage. SIF finally ended up complaining >>>>> about running out of items when processing the last file. I >>>>> reserve the right to later report that it was a miserable failure, >>>>> but it looks like I most of the code imported. >>>>> >>>>> Using the standard tools, the w2k theme, disabling faded >>>>> backgrounds and enabling fast drag, performance on an older Linux >>>>> system is ok (more or less). There are still things that take too >>>>> long, >>>>> >>>> like what? >>>> >>>> >>>>> and Pharo's responses are no better (sometimes worse) than even >>>>> software running over a remote desktop connection. We need a >>>>> speed boost, but judicious settings help a little. >>>>> >>>>> Is there a way to disable the anti-aliased fonts? In fairness, I >>>>> should try turning that off to see if any speed boost is worth the >>>>> price. >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> > > > _______________________________________________ > 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 16, 2009