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

[Pharo-project] How to have a faster image

by Mariano Martinez Peck

Hi! I want to put together the things people do to have a faster Pharo. The "slow" stuff is being identified and for the moment, perhaps it is useful people can have an image with less features but faster. All the things we put here, perhaps we can then include them in the script used to generate Pharo until the things that now are slow, are fast. This is what I do when I download a Pharo image to get it faster: ToolSet default: StandardToolSet. SystemBrowser default: OBSystemBrowserAdaptor. Preferences enable: #fastDragWindowForMorphic. Preferences disable: #dynamicProtocolActivation. Of course, there are other things like using the default Squeak theme or not using FreeType but in my case I rather use them. I hope this helps to someone. Best, Mariano

July 15, 2009

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

by Adrian Lienhard

Bill, Could you post the results of the following benchmark? 0 tinyBenchmarks This basically measures how many bytecodes and messages the VM can execute per second. Maybe that helps us to put your experience in relation to the VM and hardware speed. On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: '543236074 bytecodes/sec; 12101592 sends/sec' 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

July 15, 2009

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

by Mariano Martinez Peck

On Wed, Jul 15, 2009 at 7:34 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>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 Nod32 in Windows WON'T let you use squeak or Pharo. You have to exclude from Nod32 the folder where you have the .changes. > 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(a)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 >

July 15, 2009

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

by Schwab,Wilhelm K

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

July 15, 2009

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

by Nicolas Cellier

Not sure how you will handle this at such a high generality... Reserve optimization to subclasses maybe... Nicolas 2009/7/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > apparently > > Collection>>select: selectBlock thenCollect: collectBlock > Â Â Â Â "Utility method to improve readability." > > Â Â Â Â ^ (self select: selectBlock) collect: collectBlock > > so it would be good to avoid to do two passes on the same collection. > Any takers? > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 15, 2009

[Pharo-project] Another Pharo wallpaper

by Torsten Bergmann

Maybe the logo was inspired by the cover of this book: http://www.amazon.de/Apollonia-Cox-Im-Auge-Taifuns/dp/3866121806/ref=sr_1_1… Looks familiar Bye Torsten -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

July 15, 2009

[Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

Hi all apparently Collection>>select: selectBlock thenCollect: collectBlock "Utility method to improve readability." ^ (self select: selectBlock) collect: collectBlock so it would be good to avoid to do two passes on the same collection. Any takers? Stef

July 15, 2009

Re: [Pharo-project] Another Pharo wallpaper

by Mariano Martinez Peck

On Wed, Jul 15, 2009 at 6:17 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > I didn't know there was a pharo wallpapers collection being built. > Yes! See this post: http://n2.nabble.com/-OT--Pharo-wallpaper-td2682581.html#a2682969 > > Yeap, we have plenty lighthouses (Faro in spanish) in Argentina. "Les > Eclaireus" is one of the prettiest. > > I grew up in a city with one, and used to go up and "climb" its 160 > stairs to the top to see the seaside from very high, ironic isn't it? > :). Excellent. I love that place and love to fish there :) > > That's why I like the name of this project :) > > Some pictures of the pharo I took: > http://www.flickr.com/search/?w=82539647@N00&q=Faro&m=text > Others: > http://www.descubriquequen.com.ar/faroquequen.htm > > Regards, > > Esteban A. Maringolo > > > 2009/7/15 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > But this is ARGENTINIAN!!!! > > > > As I am building a tourism website I am collecting pictures. I found one > of a Pharo in a Argentinian province called "Tierra del Fuego". The pharo is > known as "Faro Les Eclaireurs". > > > > I attach the picture. > > > > Best, > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 15, 2009

Re: [Pharo-project] Another Pharo wallpaper

by StÃ©phane Ducasse

this is beautiful one. I liked the one of biarritz too (picture too large of the mailing-list)

July 15, 2009

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

by StÃ©phane Ducasse

> > 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

July 15, 2009