October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

While doing the SpaceTally new printSpaceAnalysis my image is locking up. Looked like it would take some time, so started playing Medal of Honor (recommend it!!) Anyhow.. Back in Pharo I have a WARNING, Event buffer overflow in the bottom...anyway to repair this without closing the image? 2010/10/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Just by cursious, could you do a SpaceTally new printSpaceAnalysis > and attach the generated file STspace.text > > In addition, you could do some cleaning, at least to decrease the size of > the image. > You can try to do "ScriptLoader new cleanUpForRelease" > > Let us know > > Mariano > > On Sat, Oct 16, 2010 at 7:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Something produces too much garbage. >> It could be anything. >> But most of the times, the cause of sluggines is finalization process. >> >> On 16 October 2010 16:37, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > I can feel this slugginess too, and we should fix that for good. >> > >> > A clue: in Squeak trunk, here are the VM stats: >> > uptime Â Â Â Â Â Â Â Â Â 0h7m59s >> > memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >> > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >> > Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >> > Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >> > Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >> > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >> > Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >> > Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >> > Since last view -7,895 >> > Â Â Â Â uptime Â Â Â Â Â 71.2s >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), >> > avg 105.0ms >> > Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >> > Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >> > >> > In Pharo: >> > uptime Â Â Â Â Â Â Â Â Â 0h6m48s >> > memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >> > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >> > Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >> > Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >> > Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >> > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >> > 278.0ms >> > Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >> > Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >> > Since last view 4,777 (85ms between GCs) >> > Â Â Â Â uptime Â Â Â Â Â 404.5s >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >> > -285.0ms >> > Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >> > Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >> > >> > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >> > Could it be object creation at each event or something like that? >> > >> > Nicolas >> > >> > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> Bart, >> >> >> >> On 16 Oct 2010, at 13:48, Bart Veenstra wrote: >> >> >> >>> Hi list, >> >>> >> >>> I have been working with Pharo for almost a month now, and I suspect >> >>> that the performance is degrading fast. UI tasks takes several seconds >> >>> to react to my keyboard. >> >>> >> >>> At work we use VAST and I have experience with VW as well and those >> >>> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> >>> works very sluggish. >> >>> >> >>> My image is about 130MB because I have loaded all dutch postcode in >> >>> memory, but that should not affect the performance of general >> >>> operations like typing with the keyboard. I am not a fast typer, but >> >>> sometimes it takes seconds to show my keyboard input. I can't use the >> >>> down key to select the right method from suggestions, because it seems >> >>> to lockup completely. >> >>> >> >>> Are there ways to speedup Pharo? I would love to use cogVM but I >> >>> haven't got gemtools working on it... >> >>> >> >>> Will upgrading to 1.1.1 fix these issues? >> >>> >> >>> Is my OS (Windows 7-64bit) causing these issues? >> >>> >> >>> Regards, >> >>> >> >>> Bart >> >> >> >> I am just guessing here, but I would suspect the slowdown to be related >> >> to completion/syntax coloring issues. >> >> You could try a pharo core image or one of lukas's builds (take >> >> development or seaside from http://hudson.lukas-renggli.ch/) >> >> In a large/old image, there could be lots of issues, of course. >> >> >> >> HTH, >> >> >> >> Sven >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

2010/10/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/10/16 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Bart, Nicolas, >> Â Â Â Bart, are you using the standard VM or Cog? >> Â Â Â Nicolas, if this is the standard VM then do the two images have the same >> value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? Â If not, that >> could account for the difference in incremental GC frequency (in Cog the IGC >> trigger mechanism is different, based on space allocated not allocation >> count). >> >> HTH >> Eliot > > Oh, comparison was not fair, I ran Squeak with COG. > When I try COG+Pharo, some updates are missing, I can't print the VMstats. > > Nicolas > Well, I mean in #spyAllEvery:on: Nicolas >> On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> I can feel this slugginess too, and we should fix that for good. >>> >>> A clue: in Squeak trunk, here are the VM stats: >>> uptime Â Â Â Â Â Â Â Â Â 0h7m59s >>> memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >>> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >>> Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >>> Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >>> Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >>> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >>> Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >>> Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >>> Since last view -7,895 >>> Â Â Â Â uptime Â Â Â Â Â 71.2s >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg >>> 105.0ms >>> Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >>> Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >>> >>> In Pharo: >>> uptime Â Â Â Â Â Â Â Â Â 0h6m48s >>> memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >>> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >>> Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >>> Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >>> Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >>> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >>> 278.0ms >>> Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >>> Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >>> Since last view 4,777 (85ms between GCs) >>> Â Â Â Â uptime Â Â Â Â Â 404.5s >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >>> -285.0ms >>> Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >>> Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >>> >>> A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >>> Could it be object creation at each event or something like that? >>> >>> Nicolas >>> >>> 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >>> > Bart, >>> > >>> > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: >>> > >>> >> Hi list, >>> >> >>> >> I have been working with Pharo for almost a month now, and I suspect >>> >> that the performance is degrading fast. UI tasks takes several seconds >>> >> to react to my keyboard. >>> >> >>> >> At work we use VAST and I have experience with VW as well and those >>> >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >>> >> works very sluggish. >>> >> >>> >> My image is about 130MB because I have loaded all dutch postcode in >>> >> memory, but that should not affect the performance of general >>> >> operations like typing with the keyboard. I am not a fast typer, but >>> >> sometimes it takes seconds to show my keyboard input. I can't use the >>> >> down key to select the right method from suggestions, because it seems >>> >> to lockup completely. >>> >> >>> >> Are there ways to speedup Pharo? I would love to use cogVM but I >>> >> haven't got gemtools working on it... >>> >> >>> >> Will upgrading to 1.1.1 fix these issues? >>> >> >>> >> Is my OS (Windows 7-64bit) causing these issues? >>> >> >>> >> Regards, >>> >> >>> >> Bart >>> > >>> > I am just guessing here, but I would suspect the slowdown to be related >>> > to completion/syntax coloring issues. >>> > You could try a pharo core image or one of lukas's builds (take >>> > development or seaside from http://hudson.lukas-renggli.ch/) >>> > In a large/old image, there could be lots of issues, of course. >>> > >>> > HTH, >>> > >>> > Sven >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >> >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

2010/10/16 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Bart, Nicolas, > Â Â Â Bart, are you using the standard VM or Cog? > Â Â Â Nicolas, if this is the standard VM then do the two images have the same > value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? Â If not, that > could account for the difference in incremental GC frequency (in Cog the IGC > trigger mechanism is different, based on space allocated not allocation > count). > > HTH > Eliot Oh, comparison was not fair, I ran Squeak with COG. When I try COG+Pharo, some updates are missing, I can't print the VMstats. Nicolas > On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> I can feel this slugginess too, and we should fix that for good. >> >> A clue: in Squeak trunk, here are the VM stats: >> uptime Â Â Â Â Â Â Â Â Â 0h7m59s >> memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >> Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >> Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >> Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >> Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >> Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >> Since last view -7,895 >> Â Â Â Â uptime Â Â Â Â Â 71.2s >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg >> 105.0ms >> Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >> Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >> >> In Pharo: >> uptime Â Â Â Â Â Â Â Â Â 0h6m48s >> memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >> Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >> Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >> Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >> 278.0ms >> Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >> Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >> Since last view 4,777 (85ms between GCs) >> Â Â Â Â uptime Â Â Â Â Â 404.5s >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >> -285.0ms >> Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >> Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >> >> A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >> Could it be object creation at each event or something like that? >> >> Nicolas >> >> 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> > Bart, >> > >> > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: >> > >> >> Hi list, >> >> >> >> I have been working with Pharo for almost a month now, and I suspect >> >> that the performance is degrading fast. UI tasks takes several seconds >> >> to react to my keyboard. >> >> >> >> At work we use VAST and I have experience with VW as well and those >> >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> >> works very sluggish. >> >> >> >> My image is about 130MB because I have loaded all dutch postcode in >> >> memory, but that should not affect the performance of general >> >> operations like typing with the keyboard. I am not a fast typer, but >> >> sometimes it takes seconds to show my keyboard input. I can't use the >> >> down key to select the right method from suggestions, because it seems >> >> to lockup completely. >> >> >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> >> haven't got gemtools working on it... >> >> >> >> Will upgrading to 1.1.1 fix these issues? >> >> >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> >> >> Regards, >> >> >> >> Bart >> > >> > I am just guessing here, but I would suspect the slowdown to be related >> > to completion/syntax coloring issues. >> > You could try a pharo core image or one of lukas's builds (take >> > development or seaside from http://hudson.lukas-renggli.ch/) >> > In a large/old image, there could be lots of issues, of course. >> > >> > HTH, >> > >> > Sven >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Eliot Miranda

Hi Bart, Nicolas, Bart, are you using the standard VM or Cog? Nicolas, if this is the standard VM then do the two images have the same value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? If not, that could account for the difference in incremental GC frequency (in Cog the IGC trigger mechanism is different, based on space allocated not allocation count). HTH Eliot On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > I can feel this slugginess too, and we should fix that for good. > > A clue: in Squeak trunk, here are the VM stats: > uptime 0h7m59s > memory 59,647,648 bytes > old 48,744,032 bytes (81.7%) > young 545,352 bytes (0.9%) > used 49,289,384 bytes (82.6%) > free 10,358,264 bytes (17.4%) > GCs 288 (1665ms between GCs) > full 0 totalling 0ms (0.0% uptime) > incr 288 totalling 486ms (0.0% uptime), avg 2.0ms > tenures 15 (avg 19 GCs/tenure) > Since last view -7,895 > uptime 71.2s > full -15 totalling -1,576ms (-2.0% uptime), avg > 105.0ms > incr -7880 totalling -1,952ms (-3.0% uptime), avg > tenures -548 (avg 14 GCs/tenure) > > In Pharo: > uptime 0h6m48s > memory 29,690,612 bytes > old 25,210,060 bytes (84.9%) > young 252,096 bytes (0.8%) > used 25,462,156 bytes (85.80000000000001%) > free 4,228,456 bytes (14.200000000000001%) > GCs 4,969 (82ms between GCs) > full 3 totalling 834ms (0.2% uptime), avg 278.0ms > incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > tenures 75 (avg 66 GCs/tenure) > Since last view 4,777 (85ms between GCs) > uptime 404.5s > full 1 totalling -285ms (-0.1% uptime), avg > -285.0ms > incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > tenures 75 (avg 63 GCs/tenure) > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > Could it be object creation at each event or something like that? > > Nicolas > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > > Bart, > > > > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > > > >> Hi list, > >> > >> I have been working with Pharo for almost a month now, and I suspect > >> that the performance is degrading fast. UI tasks takes several seconds > >> to react to my keyboard. > >> > >> At work we use VAST and I have experience with VW as well and those > >> smalltaks react to my keyboard and mouse actions instantly. But Pharo > >> works very sluggish. > >> > >> My image is about 130MB because I have loaded all dutch postcode in > >> memory, but that should not affect the performance of general > >> operations like typing with the keyboard. I am not a fast typer, but > >> sometimes it takes seconds to show my keyboard input. I can't use the > >> down key to select the right method from suggestions, because it seems > >> to lockup completely. > >> > >> Are there ways to speedup Pharo? I would love to use cogVM but I > >> haven't got gemtools working on it... > >> > >> Will upgrading to 1.1.1 fix these issues? > >> > >> Is my OS (Windows 7-64bit) causing these issues? > >> > >> Regards, > >> > >> Bart > > > > I am just guessing here, but I would suspect the slowdown to be related > to completion/syntax coloring issues. > > You could try a pharo core image or one of lukas's builds (take > development or seaside from http://hudson.lukas-renggli.ch/) > > In a large/old image, there could be lots of issues, of course. > > > > HTH, > > > > Sven > > > > > > > > > > _______________________________________________ > > 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 >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Mariano Martinez Peck

Just by cursious, could you do a SpaceTally new printSpaceAnalysis and attach the generated file STspace.text In addition, you could do some cleaning, at least to decrease the size of the image. You can try to do "ScriptLoader new cleanUpForRelease" Let us know Mariano On Sat, Oct 16, 2010 at 7:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Something produces too much garbage. > It could be anything. > But most of the times, the cause of sluggines is finalization process. > > On 16 October 2010 16:37, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I can feel this slugginess too, and we should fix that for good. > > > > A clue: in Squeak trunk, here are the VM stats: > > uptime 0h7m59s > > memory 59,647,648 bytes > > old 48,744,032 bytes (81.7%) > > young 545,352 bytes (0.9%) > > used 49,289,384 bytes (82.6%) > > free 10,358,264 bytes (17.4%) > > GCs 288 (1665ms between GCs) > > full 0 totalling 0ms (0.0% uptime) > > incr 288 totalling 486ms (0.0% uptime), avg 2.0ms > > tenures 15 (avg 19 GCs/tenure) > > Since last view -7,895 > > uptime 71.2s > > full -15 totalling -1,576ms (-2.0% uptime), avg > 105.0ms > > incr -7880 totalling -1,952ms (-3.0% uptime), avg > > tenures -548 (avg 14 GCs/tenure) > > > > In Pharo: > > uptime 0h6m48s > > memory 29,690,612 bytes > > old 25,210,060 bytes (84.9%) > > young 252,096 bytes (0.8%) > > used 25,462,156 bytes (85.80000000000001%) > > free 4,228,456 bytes (14.200000000000001%) > > GCs 4,969 (82ms between GCs) > > full 3 totalling 834ms (0.2% uptime), avg > 278.0ms > > incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > > tenures 75 (avg 66 GCs/tenure) > > Since last view 4,777 (85ms between GCs) > > uptime 404.5s > > full 1 totalling -285ms (-0.1% uptime), avg > -285.0ms > > incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > > tenures 75 (avg 63 GCs/tenure) > > > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > > Could it be object creation at each event or something like that? > > > > Nicolas > > > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > >> Bart, > >> > >> On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > >> > >>> Hi list, > >>> > >>> I have been working with Pharo for almost a month now, and I suspect > >>> that the performance is degrading fast. UI tasks takes several seconds > >>> to react to my keyboard. > >>> > >>> At work we use VAST and I have experience with VW as well and those > >>> smalltaks react to my keyboard and mouse actions instantly. But Pharo > >>> works very sluggish. > >>> > >>> My image is about 130MB because I have loaded all dutch postcode in > >>> memory, but that should not affect the performance of general > >>> operations like typing with the keyboard. I am not a fast typer, but > >>> sometimes it takes seconds to show my keyboard input. I can't use the > >>> down key to select the right method from suggestions, because it seems > >>> to lockup completely. > >>> > >>> Are there ways to speedup Pharo? I would love to use cogVM but I > >>> haven't got gemtools working on it... > >>> > >>> Will upgrading to 1.1.1 fix these issues? > >>> > >>> Is my OS (Windows 7-64bit) causing these issues? > >>> > >>> Regards, > >>> > >>> Bart > >> > >> I am just guessing here, but I would suspect the slowdown to be related > to completion/syntax coloring issues. > >> You could try a pharo core image or one of lukas's builds (take > development or seaside from http://hudson.lukas-renggli.ch/) > >> In a large/old image, there could be lots of issues, of course. > >> > >> HTH, > >> > >> Sven > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

Something produces too much garbage. It could be anything. But most of the times, the cause of sluggines is finalization process. On 16 October 2010 16:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I can feel this slugginess too, and we should fix that for good. > > A clue: in Squeak trunk, here are the VM stats: > uptime Â Â Â Â Â Â Â Â Â 0h7m59s > memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) > Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) > Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) > Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) > Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms > Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) > Since last view -7,895 > Â Â Â Â uptime Â Â Â Â Â 71.2s > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms > Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg > Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) > > In Pharo: > uptime Â Â Â Â Â Â Â Â Â 0h6m48s > memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) > Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) > Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) > Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg 278.0ms > Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) > Since last view 4,777 (85ms between GCs) > Â Â Â Â uptime Â Â Â Â Â 404.5s > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg -285.0ms > Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > Could it be object creation at each event or something like that? > > Nicolas > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> Bart, >> >> On 16 Oct 2010, at 13:48, Bart Veenstra wrote: >> >>> Hi list, >>> >>> I have been working with Pharo for almost a month now, and I suspect >>> that the performance is degrading fast. UI tasks takes several seconds >>> to react to my keyboard. >>> >>> At work we use VAST and I have experience with VW as well and those >>> smalltaks react to my keyboard and mouse actions instantly. But Pharo >>> works very sluggish. >>> >>> My image is about 130MB because I have loaded all dutch postcode in >>> memory, but that should not affect the performance of general >>> operations like typing with the keyboard. I am not a fast typer, but >>> sometimes it takes seconds to show my keyboard input. I can't use the >>> down key to select the right method from suggestions, because it seems >>> to lockup completely. >>> >>> Are there ways to speedup Pharo? I would love to use cogVM but I >>> haven't got gemtools working on it... >>> >>> Will upgrading to 1.1.1 fix these issues? >>> >>> Is my OS (Windows 7-64bit) causing these issues? >>> >>> Regards, >>> >>> Bart >> >> I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. >> You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) >> In a large/old image, there could be lots of issues, of course. >> >> HTH, >> >> Sven >> >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Schwab,Wilhelm K

Are those negative numbers in the Squeak stats? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Saturday, October 16, 2010 9:37 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Speeding up Pharo 1.1 I can feel this slugginess too, and we should fix that for good. A clue: in Squeak trunk, here are the VM stats: uptime 0h7m59s memory 59,647,648 bytes old 48,744,032 bytes (81.7%) young 545,352 bytes (0.9%) used 49,289,384 bytes (82.6%) free 10,358,264 bytes (17.4%) GCs 288 (1665ms between GCs) full 0 totalling 0ms (0.0% uptime) incr 288 totalling 486ms (0.0% uptime), avg 2.0ms tenures 15 (avg 19 GCs/tenure) Since last view -7,895 uptime 71.2s full -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms incr -7880 totalling -1,952ms (-3.0% uptime), avg tenures -548 (avg 14 GCs/tenure) In Pharo: uptime 0h6m48s memory 29,690,612 bytes old 25,210,060 bytes (84.9%) young 252,096 bytes (0.8%) used 25,462,156 bytes (85.80000000000001%) free 4,228,456 bytes (14.200000000000001%) GCs 4,969 (82ms between GCs) full 3 totalling 834ms (0.2% uptime), avg 278.0ms incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms tenures 75 (avg 66 GCs/tenure) Since last view 4,777 (85ms between GCs) uptime 404.5s full 1 totalling -285ms (-0.1% uptime), avg -285.0ms incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms tenures 75 (avg 63 GCs/tenure) A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. Could it be object creation at each event or something like that? Nicolas 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > Bart, > > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > >> Hi list, >> >> I have been working with Pharo for almost a month now, and I suspect >> that the performance is degrading fast. UI tasks takes several seconds >> to react to my keyboard. >> >> At work we use VAST and I have experience with VW as well and those >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> works very sluggish. >> >> My image is about 130MB because I have loaded all dutch postcode in >> memory, but that should not affect the performance of general >> operations like typing with the keyboard. I am not a fast typer, but >> sometimes it takes seconds to show my keyboard input. I can't use the >> down key to select the right method from suggestions, because it seems >> to lockup completely. >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> haven't got gemtools working on it... >> >> Will upgrading to 1.1.1 fix these issues? >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> Regards, >> >> Bart > > I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. > You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) > In a large/old image, there could be lots of issues, of course. > > HTH, > > Sven > > > > > _______________________________________________ > 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

Oct. 16, 2010

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b12

by Philippe Marschall

On 11.10.2010 07:01, John M McIntosh wrote: > I've stuck a version (5.8b12) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b12.app.zip > > This is based on the latest Cog VM source (oct 10/10/10). > > Changes to the support logic: > > (a) Supply file create/mod times & size based on target of symbolic link versus the link file node. > (b) Untrusted directory was set wrong, use same default value as 4.2.x VM ~/Library/Preferences/Squeak/Internet/My Squeak/ > (c) There is no -pathenc option > (d) Attempt to integrate changes into Cog branch to allow you to compile VM from the Cog branch. > *** This does not work yet, 90% there, Eliot and I still have some pencil sharping to do... *** > > Now the big news is that I pushed a version of the Squeak Cog stack VM to the Apple App Store! > > It's rough, but it's a candidate for review by Apple's special App review committee. It does not have socket support and we are seeing if they > allow us to move image/change files in and out of the Documents folder via a desktop machine. I should know more by next weekend. > > If accepted then I am looking to the Smalltalk community to help in building a viable image to allow people to edit source code on an iPad. > > > Lastly, yes something broken in open/gl on os-x 10.4 I hope to look at the issue this week. I have to download the LocalePlugin to get the correct timezone offset (otherwise I get a primitive failure) but I guess that's to be expected. Otherwise it seems to work. Cheers Philippe

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

Before I started loading all the postcodes in the system, the image was about 80 MB. after loading all the postcodes it was about 108MB. Stuff I have loaded: Seaside (Complete) JQWidgetBox GemTools SqeaukSSL WebClient XMLSupport MockGemstone SqueakDBX MySQL CSV Query Extensions and my own projects. Looks like a typical image for me :) For the postcode lookup system, i have 397024 streets, (inst vars: city postcode name low high even latitude longitude), 9396 cities and 12 provinces. Not a complex model. They all are stored in IdentityBags. Indexes will be maintained by GemStone in the future, but for now I retrieve the address using: self streets select: [:each | each postcode = postcode ]. How do I get the output from the process browser in text? I only have about 13 processes where the input events fetching process takes about 30 procent and the rest is idle. Regards, Bart 2010/10/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Bart, > > My image is 40 MB right now. Â That means you have about 100 MB of data? Â How do you store it? Â How many objects are there? Â Are they of fixed size? Â If so, you might try a quick experiment using a String or ByteArray wrapped with something that knows how to find a given code. Â You might be putting a pretty good load on the GC and using a blob to hold the data might help. Â I'm not sure where we are with respect to having a generational GC that would tenure and shrug off old objects. > > IIRC, Alan Kay reported having a 160 MB Squeak image for demos, but that was many versions ago, so I hesitate to draw any comparisons. Â If you can find or get a copy of it, it might be interesting to open it in current VM to see how it performs. > > Syntax highlighting is a possible offender, though I would not expect delays like you are describing. Â Do you by chance access the image over a remote desktop connection? Â Do you notice the problem with only certain methods? > > What do you see in Tools|Process Browser? Â If you have a large number or processes running, it might explain a lot. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Saturday, October 16, 2010 8:24 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Speeding up Pharo 1.1 > > Bart, > > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > >> Hi list, >> >> I have been working with Pharo for almost a month now, and I suspect >> that the performance is degrading fast. UI tasks takes several seconds >> to react to my keyboard. >> >> At work we use VAST and I have experience with VW as well and those >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> works very sluggish. >> >> My image is about 130MB because I have loaded all dutch postcode in >> memory, but that should not affect the performance of general >> operations like typing with the keyboard. I am not a fast typer, but >> sometimes it takes seconds to show my keyboard input. I can't use the >> down key to select the right method from suggestions, because it seems >> to lockup completely. >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> haven't got gemtools working on it... >> >> Will upgrading to 1.1.1 fix these issues? >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> Regards, >> >> Bart > > I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. > You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) > In a large/old image, there could be lots of issues, of course. > > HTH, > > Sven > > > > > _______________________________________________ > 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 >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Schwab,Wilhelm K

Bart, My image is 40 MB right now. That means you have about 100 MB of data? How do you store it? How many objects are there? Are they of fixed size? If so, you might try a quick experiment using a String or ByteArray wrapped with something that knows how to find a given code. You might be putting a pretty good load on the GC and using a blob to hold the data might help. I'm not sure where we are with respect to having a generational GC that would tenure and shrug off old objects. IIRC, Alan Kay reported having a 160 MB Squeak image for demos, but that was many versions ago, so I hesitate to draw any comparisons. If you can find or get a copy of it, it might be interesting to open it in current VM to see how it performs. Syntax highlighting is a possible offender, though I would not expect delays like you are describing. Do you by chance access the image over a remote desktop connection? Do you notice the problem with only certain methods? What do you see in Tools|Process Browser? If you have a large number or processes running, it might explain a lot. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Saturday, October 16, 2010 8:24 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Speeding up Pharo 1.1 Bart, On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > Hi list, > > I have been working with Pharo for almost a month now, and I suspect > that the performance is degrading fast. UI tasks takes several seconds > to react to my keyboard. > > At work we use VAST and I have experience with VW as well and those > smalltaks react to my keyboard and mouse actions instantly. But Pharo > works very sluggish. > > My image is about 130MB because I have loaded all dutch postcode in > memory, but that should not affect the performance of general > operations like typing with the keyboard. I am not a fast typer, but > sometimes it takes seconds to show my keyboard input. I can't use the > down key to select the right method from suggestions, because it seems > to lockup completely. > > Are there ways to speedup Pharo? I would love to use cogVM but I > haven't got gemtools working on it... > > Will upgrading to 1.1.1 fix these issues? > > Is my OS (Windows 7-64bit) causing these issues? > > Regards, > > Bart I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) In a large/old image, there could be lots of issues, of course. HTH, Sven _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

I can feel this slugginess too, and we should fix that for good. A clue: in Squeak trunk, here are the VM stats: uptime 0h7m59s memory 59,647,648 bytes old 48,744,032 bytes (81.7%) young 545,352 bytes (0.9%) used 49,289,384 bytes (82.6%) free 10,358,264 bytes (17.4%) GCs 288 (1665ms between GCs) full 0 totalling 0ms (0.0% uptime) incr 288 totalling 486ms (0.0% uptime), avg 2.0ms tenures 15 (avg 19 GCs/tenure) Since last view -7,895 uptime 71.2s full -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms incr -7880 totalling -1,952ms (-3.0% uptime), avg tenures -548 (avg 14 GCs/tenure) In Pharo: uptime 0h6m48s memory 29,690,612 bytes old 25,210,060 bytes (84.9%) young 252,096 bytes (0.8%) used 25,462,156 bytes (85.80000000000001%) free 4,228,456 bytes (14.200000000000001%) GCs 4,969 (82ms between GCs) full 3 totalling 834ms (0.2% uptime), avg 278.0ms incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms tenures 75 (avg 66 GCs/tenure) Since last view 4,777 (85ms between GCs) uptime 404.5s full 1 totalling -285ms (-0.1% uptime), avg -285.0ms incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms tenures 75 (avg 63 GCs/tenure) A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. Could it be object creation at each event or something like that? Nicolas 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > Bart, > > On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > >> Hi list, >> >> I have been working with Pharo for almost a month now, and I suspect >> that the performance is degrading fast. UI tasks takes several seconds >> to react to my keyboard. >> >> At work we use VAST and I have experience with VW as well and those >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> works very sluggish. >> >> My image is about 130MB because I have loaded all dutch postcode in >> memory, but that should not affect the performance of general >> operations like typing with the keyboard. I am not a fast typer, but >> sometimes it takes seconds to show my keyboard input. I can't use the >> down key to select the right method from suggestions, because it seems >> to lockup completely. >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> haven't got gemtools working on it... >> >> Will upgrading to 1.1.1 fix these issues? >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> Regards, >> >> Bart > > I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. > You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) > In a large/old image, there could be lots of issues, of course. > > HTH, > > Sven > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Sven Van Caekenberghe

Bart, On 16 Oct 2010, at 13:48, Bart Veenstra wrote: > Hi list, > > I have been working with Pharo for almost a month now, and I suspect > that the performance is degrading fast. UI tasks takes several seconds > to react to my keyboard. > > At work we use VAST and I have experience with VW as well and those > smalltaks react to my keyboard and mouse actions instantly. But Pharo > works very sluggish. > > My image is about 130MB because I have loaded all dutch postcode in > memory, but that should not affect the performance of general > operations like typing with the keyboard. I am not a fast typer, but > sometimes it takes seconds to show my keyboard input. I can't use the > down key to select the right method from suggestions, because it seems > to lockup completely. > > Are there ways to speedup Pharo? I would love to use cogVM but I > haven't got gemtools working on it... > > Will upgrading to 1.1.1 fix these issues? > > Is my OS (Windows 7-64bit) causing these issues? > > Regards, > > Bart I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/) In a large/old image, there could be lots of issues, of course. HTH, Sven

Oct. 16, 2010

[Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

Hi list, I have been working with Pharo for almost a month now, and I suspect that the performance is degrading fast. UI tasks takes several seconds to react to my keyboard. At work we use VAST and I have experience with VW as well and those smalltaks react to my keyboard and mouse actions instantly. But Pharo works very sluggish. My image is about 130MB because I have loaded all dutch postcode in memory, but that should not affect the performance of general operations like typing with the keyboard. I am not a fast typer, but sometimes it takes seconds to show my keyboard input. I can't use the down key to select the right method from suggestions, because it seems to lockup completely. Are there ways to speedup Pharo? I would love to use cogVM but I haven't got gemtools working on it... Will upgrading to 1.1.1 fix these issues? Is my OS (Windows 7-64bit) causing these issues? Regards, Bart

Oct. 16, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

2010/10/15 <mkobetic(a)gmail.com>: > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> I've tested this strategy, and it works well: >> >> - use accessors self input/self output instead of inst. var. >> - lazily initialize the input for Collection and File > > Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > The tests interleaving read/write are #testWriteFromCollectionAt #testWriteFromStream #testWriteTransformHexToByte #testReadWriteLargeAmount Then #testGetPastEnd also relies on become: on close... If we change the grown policy: destination := destination grownBy: (destination size max: 10) instead of: destination := destination grownBy: (destination size max: 1) then the test does not pass. This also is because I used: input := outer terminal reading rather than: input := outer conclusion reading >> In collection tests, I have used >> Â Â Â ^input ifNil:[input := outer terminal reading] >> where: outer := output := collection writing. >> This is because some Block transforms can't access the terminal collection... > > Not sure what you mean, but it will probably get clearer when I go do it. > BlockWriteStream terminal answers a block... But yes, it will be clearer when debugging it. > BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. > > Martin > Nice. Squeak lack package comment.... :( Nicolas

Oct. 16, 2010

[Pharo-project] [ANN] Atomic collections.

by Igor Stasenko

Hello, as a result of recently happened discussion about atomic operations, i implemented two kinds of thread-safe queues FIFO and LIFO, which using atomic operations, instead of semaphore to add/remove items. You may review it by loading the code from SqueakSource: MCHttpRepository location: 'http://www.squeaksource.com/Atomics' user: '' password: '' FIFOQueue scales much better than SharedQueue, and after some additional testing can fully replace it. I tested FIFOQueue by replacing a SharedQueue class for EventSensor (a core system part, responsible for delivering events). In attached file you can find a patch, which will make your sensor to work with FIFOQueue, after you save image, or do 'EventSensor install'. There are also a heavy-concurrency tests in corresponding test classes, which is passing ok. Concurrency is highly complex field, thus i won't be surprised if code still contains a bugs. Code license is MIT, moreover a repository is publicly writeable, so if you wanna add tests, benchmarks, fixes, or implement new kind of lock-free container, feel free to do it. Any feedback is welcome. -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] Example of non-concurrent code :)

by John M McIntosh

Igor, take a look back in the messages from January 25th 2010 Re: [Pharo-project] new mac menu code There may be something related there? On 2010-10-15, at 9:41 PM, Igor Stasenko wrote: > mouseTrailFrom: currentBuf > "Current event, a mouse event buffer, is about to be processed. If > there are other similar mouse events queued up, then drop them from > the queue, and report the positions inbetween." > > | nextEvent trail | > trail := (Array new: 1) writeStream. > trail nextPut: currentBuf third @ currentBuf fourth. > *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: > [nextEvent first = currentBuf first > ifFalse: [^trail contents "different event type"]. > nextEvent fifth = currentBuf fifth > ifFalse: [^trail contents "buttons changed"]. > nextEvent sixth = currentBuf sixth > ifFalse: [^trail contents "modifiers changed"]. > "nextEvent is similar. Remove it from the queue, and check the next." > *b* nextEvent := Sensor nextEvent. > trail nextPut: nextEvent third @ nextEvent fourth]. > ^trail contents > > > Here, the bug: > first it sends #peekEvent and its not nil. > Okay, then after some logic voodo, it sends nextEvent, without > precaution, that it may also answer nil! > > So, if some other process get between these two sends (*a*, *b*) and > fetch/flush all events, a code will fail, > because > 'nextEvent third' is DNU , when nextEvent == nil. > > The fix is simple: > > nextEvent := Sensor nextEvent. > nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] > > Both Pharo & Squeak contain this bug. But this method slightly differs > from each other. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 16, 2010

[Pharo-project] Example of non-concurrent code :)

by Igor Stasenko

mouseTrailFrom: currentBuf "Current event, a mouse event buffer, is about to be processed. If there are other similar mouse events queued up, then drop them from the queue, and report the positions inbetween." | nextEvent trail | trail := (Array new: 1) writeStream. trail nextPut: currentBuf third @ currentBuf fourth. *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: [nextEvent first = currentBuf first ifFalse: [^trail contents "different event type"]. nextEvent fifth = currentBuf fifth ifFalse: [^trail contents "buttons changed"]. nextEvent sixth = currentBuf sixth ifFalse: [^trail contents "modifiers changed"]. "nextEvent is similar. Remove it from the queue, and check the next." *b* nextEvent := Sensor nextEvent. trail nextPut: nextEvent third @ nextEvent fourth]. ^trail contents Here, the bug: first it sends #peekEvent and its not nil. Okay, then after some logic voodo, it sends nextEvent, without precaution, that it may also answer nil! So, if some other process get between these two sends (*a*, *b*) and fetch/flush all events, a code will fail, because 'nextEvent third' is DNU , when nextEvent == nil. The fix is simple: nextEvent := Sensor nextEvent. nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] Both Pharo & Squeak contain this bug. But this method slightly differs from each other. -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

[Pharo-project] SharedQueue doesn't scale

by Igor Stasenko

Hello, just out of interest, i tried to compare the speed of my FIFOQueue implementation and SharedQueue, using Levente's benchmarks for stack: "The linked Stack implementation" (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := FIFOQueue new. { [ 1 to: 1000000 do: [ :each | stack nextPut: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack next ] ] timeToRun } ] #(#(291 69) #(170 65) #(168 66) #(168 65) #(168 65)) Then i changed FIFOQueue to SharedQueue and run it again.. waiting 1 minute.. wait a bit more.. then i came to smoke.. and after returning, it was still running.. i interrupted it, and inspected the queue size.. it was slightly above 300000 items. Of course, SharedQueue usually not used in scenarios, where you need to push such large number of items. So, its just a warning. Btw, here is another comparison (Stack vs thread-safe LIFO queue): (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := Stack new. { [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] Stack: #(#(166 94) #(160 90) #(162 91) #(162 92) #(160 92)) LIFOQueue: #(#(172 250) #(174 248) #(172 250) #(174 252) #(172 250)) Yes, it is slower (mainly for reading). But it is price for being thread safe :) -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

I don't like it either, but sometimes you have to use it... 2010/10/15 laurent laffont <laurent.laffont(a)gmail.com> > PerformedExperiment class >> >> for: anExperiment >> startedAt: aStartTime >> stopedAt: aStopTime >> madeBy: aParticipant >> with: aCollectionOfTasks. >> | instance | >> instance := self new. >> instance >> initializeFor: anExperiment >> startedAt: aStartTime >> stopedAt: aStopTime >> madeBy: aParticipant >> with: aCollectionOfTasks. >> ^ instance >> > > > I don't really like this way of formatting the message with line breaks. I > agree on Inline Message Pattern in Kent Beck's Smalltalk Best Practice > Patterns. There's the draft here > > http://stephane.ducasse.free.fr/FreeBooks/BestSmalltalkPractices/Draft-Smal… > > Look at p.127 / 128 > > > Cheers, > > Laurent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

thanks levente! this is always nice to read such kind of post since they educate us and we need that :) I want to be taught a lot :) Stef On Oct 15, 2010, at 6:33 PM, Levente Uzonyi wrote: > On Thu, 14 Oct 2010, jaayer wrote: > >> There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. >> >> Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: >> >> Pushing is roughly ~30% faster: >> r1 :=[100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]]] timeToRun. >> r2 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]]] timeToRun. >> 100 - ((r1 / r2) asFloat * 100). >> >> as is pushing + popping: >> r3 := [100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]. >> 10 timesRepeat: [s pop]]] timeToRun. >> r4 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]. >> 10 timesRepeat: [oc removeLast]]] timeToRun. >> 100 - ((r3 / r4) asFloat * 100). > > Please write more realistic benchmarks. Adding 10 elements to your Stack implementation won't make it's array grow. Also the benchmark measures a lot of other stuff besides the cost of push and pop. Something like this should do it: > > "The linked Stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(167 88) #(169 91) #(169 88) #(166 87) #(166 88)) > > "OrderedCollection" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := OrderedCollection new. > { > [ 1 to: 1000000 do: [ :each | stack addLast: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack removeLast ] ] timeToRun } ] > #(#(87 98) #(87 100) #(87 98) #(88 97) #(87 99)) > > "The new stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(89 62) #(90 63) #(89 62) #(89 62) #(89 64)) > > All benchmarks were run in the latest Squeak 4.2 alpha using the latest CogVM. > > Conclusion: OrderedCollection >> #removeLast uses #emptyCheck which is slow. Other than that the difference between OrderedCollection and an array-based stack implementation is neglible in Squeak using CogVM. > > Replacing > self emptyCheck > with > lastIndex < firstIndex ifTrue: [ self errorEmptyCollection] > in OrderedCollection >> #removeLast and running the benchmark again gives the following results: > #(#(88 65) #(90 66) #(89 66) #(88 68) #(87 66)) > > > Also please send #postCopy to super if you implement #postCopy. > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010

Re: [Pharo-project] Xtreams vs become:

by mkobetic＠gmail.com

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > I've tested this strategy, and it works well: > > - use accessors self input/self output instead of inst. var. > - lazily initialize the input for Collection and File Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > In collection tests, I have used > ^input ifNil:[input := outer terminal reading] > where: outer := output := collection writing. > This is because some Block transforms can't access the terminal collection... Not sure what you mean, but it will probably get clearer when I go do it. BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. Martin

Oct. 15, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Ramon Leon

On 10/15/2010 9:40 AM, Simon Denier wrote: > > On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > >> They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. >> Instances variables, are blue (instead of black), the same as parameters,etc... >> >> is there a way to recover the original colors? do we wanted this change or it is accidental ? > > I think the colors in 1.0 were inherited from the dev images build by Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who maintains Shout? Am I wrong? I preferred the old colors as well and switched them back. The new ones are just too weak, not enough color, not enough bold, can't tell things apart. -- Ramon Leon http://onsmalltalk.com

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

Didier, I would go along with "clearly" with the code in Smalltalk; I do not have enough experience with Java to pronounce it too slow to do the job. Nor can I claim to understand what is involved in a continental weather forecast. When it comes to transforming 500,000 sample time series, I have a little more sense of it. There the problem is not so much the cost of processing one of them, it's that I have many of them to analyze and summarize. It might be that you do not address the expensive things that I use. For things like non-linear regression with modest numbers of points, the speed penalty of even Smalltalk might indeed not be a deterrent. In terms of my GPL/GSL struggle, the code most likely to be put at risk by GPL is what is needed to do least squares, root finding, and regression; it is also (however indirectly) connected to the more poorly designed parts of GSL. The transforms are relatively clean, and would be almost directly accessible with only modest improvements to Pharo. The few vector operations that I have used from BLAS can be clean-roomed with little effort. This could work out nicely. I'm not sure I agree that communication with external libraries is "unstable." I have done a lot of it for a long time with good results. It is true that our current FFI is not as good as Dolphin's, but it does work as far as it goes. It can be readily modified to provide diagnostic information that is suppressed by default and that helps a lot in getting things to work. NativeBoost and/or Alien will hopefully address callbacks and get closer to Dolphin's handling of structure field types. Bill ________________________________________ From: Didier Besset [didier(a)ieee.org] Sent: Friday, October 15, 2010 11:09 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license You just have to see what is good for you. Clearly, you won't compute the weather forecast each day for whole Europe in ST or Java. However, I found that making least-square fits within the time required to refresh a screen perfecttly acceptable compared to the unstability of cross language communication. Cheers, Didier On 14/10/2010 22:36, Schwab,Wilhelm K wrote: > That is wonderful news! > > Didier, There is a natural question that arises: what are the performance implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have not tried number crunching with Cog or NativeBoost doing some of the expensive lifting, but absent those advantages, the benefit from coding tight loops in C has been nothing short of eerie. I have never tried Java for it. If there is a speed boost to be had, would a port offend you? I am a pragmatist, so it would begin one function at a time, chosen by the type of work I do and driven by when the machine grunts. > > Thanks, > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, October 14, 2010 4:02 PM > To: Pharo Development; The general-purpose Squeak developers list; ESUG Mailing list > Cc: Didier H. Besset > Subject: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Begin forwarded message: > >> From: Didier Besset<didier(a)ieee.org> >> Date: October 14, 2010 8:06:52 PM GMT+02:00 >> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Subject: Disclaimer >> >> I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. >> >> Didier Besset > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 15, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Simon Denier

On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. > Instances variables, are blue (instead of black), the same as parameters,etc... > > is there a way to recover the original colors? do we wanted this change or it is accidental ? I think the colors in 1.0 were inherited from the dev images build by Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who maintains Shout? Am I wrong? I liked the colors in 1.0, but now I am accustomed to the current theme, which is very keen to the eye, except for two things that I change: - distinguish instance vars/class vars from other variables: I use a brownish color for that, as I want to see at once methods accessing the state of the object - distinguish class references: I use bold black as in the previous style, as I want to quickly catch hard dependencies in the code To customize colors, two solutions: 1) hack SHTextStylerST80>>defaultStyleTable 2) load latest Shout and use Settings (then you should be able to save/load your style), since there is now a Settings interface -- Simon

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Levente Uzonyi

On Thu, 14 Oct 2010, jaayer wrote: > There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. > > Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: > > Pushing is roughly ~30% faster: > r1 :=[100000 timesRepeat: [ > s := Stack new. > 10 timesRepeat: [s push: #foo]]] timeToRun. > r2 := [100000 timesRepeat: [ > oc := OrderedCollection new. > 10 timesRepeat: [oc addLast: #foo]]] timeToRun. > 100 - ((r1 / r2) asFloat * 100). > > as is pushing + popping: > r3 := [100000 timesRepeat: [ > s := Stack new. > 10 timesRepeat: [s push: #foo]. > 10 timesRepeat: [s pop]]] timeToRun. > r4 := [100000 timesRepeat: [ > oc := OrderedCollection new. > 10 timesRepeat: [oc addLast: #foo]. > 10 timesRepeat: [oc removeLast]]] timeToRun. > 100 - ((r3 / r4) asFloat * 100). Please write more realistic benchmarks. Adding 10 elements to your Stack implementation won't make it's array grow. Also the benchmark measures a lot of other stuff besides the cost of push and pop. Something like this should do it: "The linked Stack implementation" (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := Stack new. { [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] #(#(167 88) #(169 91) #(169 88) #(166 87) #(166 88)) "OrderedCollection" (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := OrderedCollection new. { [ 1 to: 1000000 do: [ :each | stack addLast: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack removeLast ] ] timeToRun } ] #(#(87 98) #(87 100) #(87 98) #(88 97) #(87 99)) "The new stack implementation" (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := Stack new. { [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] #(#(89 62) #(90 63) #(89 62) #(89 62) #(89 64)) All benchmarks were run in the latest Squeak 4.2 alpha using the latest CogVM. Conclusion: OrderedCollection >> #removeLast uses #emptyCheck which is slow. Other than that the difference between OrderedCollection and an array-based stack implementation is neglible in Squeak using CogVM. Replacing self emptyCheck with lastIndex < firstIndex ifTrue: [ self errorEmptyCollection] in OrderedCollection >> #removeLast and running the benchmark again gives the following results: #(#(88 65) #(90 66) #(89 66) #(88 68) #(87 66)) Also please send #postCopy to super if you implement #postCopy. Levente

Oct. 15, 2010