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