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

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

by Lukas Renggli

> 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

July 16, 2009

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

by Lukas Renggli

> I've noticed something that seems unusual to me. Â Choose save and quit, and the writing cursor appears, disappears, and the image is almost immediately gone after that happens. Â Choose save, and the cursor appears, sticks around for about the same amount of time as for save and quit (this part is a little bit of a stretch), and then the image becomes unresponsive for (depending) one or more seconds. That's probably because startup scripts are run. In the first case this happens when the image comes up. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 16, 2009

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

by Schwab,Wilhelm K

Hello all, I've noticed something that seems unusual to me. Choose save and quit, and the writing cursor appears, disappears, and the image is almost immediately gone after that happens. Choose save, and the cursor appears, sticks around for about the same amount of time as for save and quit (this part is a little bit of a stretch), and then the image becomes unresponsive for (depending) one or more seconds. Anything? When combined with comments people have made about the event loop, I wonder whether the system idles when it should not, or something like that??? Sorry if this is a wild goose chase. Bill

July 16, 2009

Re: [Pharo-project] What is the story for fasterSets

by Ralph Boland

2009/7/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > what is the conclusion for the faster sets? > > Stef > I am not quite sure what the conclusion was but based on the comments I suggest that I release a new version of FasterSets with the following changes: 1) change method name noCompareAdd: to noCompareOrGrowAdd: This helps emphasize that it can't be used publicly. 2) Add methods addNew: and nastyAddNew: I tried to generate a discussion on these methods but none was forthcoming. I am inclined to add them to FasterSets so that anybody who wants to can use them. I assume they will NOT be added to Pharo. The method noCompareAdd: currently updates the tally value and it has been proposed to move this step outside of noCompareAdd: or create a method noCompareAddAll: or both. I can do this or someone else can. If someone else does this then I strongly encourage that that they release the change to FasterSets first. I will add whoever does this to the list of those able to modify FasterSets. Note that I want to incorporate FasterSets to any version of Smalltalk that would benefit from it so I want it to contain the final code that Pharo uses. Also note that I was recently told that GNU Smalltalk already does what FasterSets does. Regards, Ralph Boland

July 16, 2009

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

by Hernan Wilkinson

Just a quick thought: select: selectBlock thenCollect: collectBlock | newCollection | newCollection := self species new. self do: [:each | (selectBlock value: each) ifTrue: [newCollection add: (collectBlock value: each)]]. ^newCollection But, we can not say that is going to be faster always... if newCollection grows too much, it could be slower. Also it wont work on SortedCollection becuase SortedCollection has to return an OrderCollection and species returns a SortedCollection... I did not see test for this message, it would be great to have them and try :-) On Wed, Jul 15, 2009 at 5:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 16, 2009

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

by Schwab,Wilhelm K

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

July 16, 2009

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

by Schwab,Wilhelm K

Alain, I'll reply twice vs. gluing these together. Here, I have remoted to an XP machine, but hopefully that won't clobber the benchmark (if it does, I can repeat it later): '141828254 bytecodes/sec; 6938144 sends/sec' Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec Sent: Wednesday, July 15, 2009 5: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

July 16, 2009

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

by Alain Plantec

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

July 15, 2009

Re: [Pharo-project] How to have a faster image

by Mariano Martinez Peck

2009/7/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Mariano, > > What is the dynamic protocol setting? > dynamic protocol are those "categories" (actually they are not actually categories but in the browser they are show where the categories are) that are dynamically processed and they are shown with the pattern "--xxx(number)--". Examples: --uncommented(1)-- --override(2)-- What I do is to have this disable. When I will make a release of my software I enable them and check all my classes for those dynamic protocols. Perhaps this can also be done using SmallLint. > I spotted that recently and intended to run it down. Is there a good way > to toggle free type? > I really don't know. I know a hack hahhaa: remove the folder where the fonts are aha It is welcome to know a easy way no enable/disable it. > The preference browser check boxes that I think would do it (hinting), just > seem to go into some type of broken state. > Which preference? I don't saw anyone related to FreeType. > This is a great idea, and probably deserves a wiki page. > > Yes it does. But as not all have write access we can discuss it here and then I add a wiki page for this. You said in another mail to disable fadedBackgroundWindows. Did you notice a speed increase with this? Anyway...by default it isn't activated. I wasn't aware of this preference, but it is useful :) Best, Mariano > Bill > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Wednesday, July 15, 2009 3:50 PM > *To:* Pharo Development > *Subject:* [Pharo-project] How to have a faster image > > 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 > > _______________________________________________ > 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] How to have a faster image

by Schwab,Wilhelm K

Mariano, What is the dynamic protocol setting? I spotted that recently and intended to run it down. Is there a good way to toggle free type? The preference browser check boxes that I think would do it (hinting), just seem to go into some type of broken state. This is a great idea, and probably deserves a wiki page. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, July 15, 2009 3:50 PM To: Pharo Development Subject: [Pharo-project] How to have a faster image 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