Speeding up Pharo 1.1
Locked
123
123
 
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sven Van Caekenberghe
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: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] Sent: Saturday, October 16, 2010 8:24 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: > 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: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] > Sent: Saturday, October 16, 2010 8:24 AM > To: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
Are those negative numbers in the Squeak stats?
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Nicolas Cellier [[hidden email]] Sent: Saturday, October 16, 2010 9:37 AM To: [hidden email] 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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Speeding up Pharo 1.1
|
|
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 <[hidden email]> wrote: Something produces too much garbage. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> wrote: I can feel this slugginess too, and we should fix that for good. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/10/16 Eliot Miranda <[hidden email]>:
> 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 > <[hidden email]> 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 <[hidden email]>: >> > 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 >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/10/16 Nicolas Cellier <[hidden email]>:
> 2010/10/16 Eliot Miranda <[hidden email]>: >> 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 >> <[hidden email]> 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 <[hidden email]>: >>> > 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 >>> > [hidden email] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
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 <[hidden email]>: > 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 <[hidden email]> 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 >> <[hidden email]> 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 <[hidden email]>: >> >> 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 >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Bart Veenstra
On Sat, 16 Oct 2010, 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. That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression: (WeakArray classPool at: #FinalizationDependents) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size ] There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing). If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive. Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. Levente > > 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 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
Can you check in 1.2 because I seem to remember that it was fixed?
TX On Oct 16, 2010, at 8:51 PM, Nicolas Cellier wrote: > 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Bart Veenstra
On Oct 17, 2010, at 12:37 AM, Levente Uzonyi wrote: > On Sat, 16 Oct 2010, 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. > > That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression: > > (WeakArray classPool at: #FinalizationDependents) > select: [ :each | each notNil ] > thenCollect: [ :each | each class -> each size ] > > There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing). > If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive. > Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. The idea was to remove the poll behavior now I do not remember if the semaphore was removed or simply was waiting for the windows vm to get the support and was forgotten. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Speeding up Pharo 1.1
|
|
In reply to this post by Levente Uzonyi-2
Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>: > Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. > > > Levente It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On 17 October 2010 01:37, Levente Uzonyi <[hidden email]> wrote:
> On Sat, 16 Oct 2010, 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. > > That kind of sluggishness is probably related to finalization/gc. Please > send us the result of the following expression: > > (WeakArray classPool at: #FinalizationDependents) > select: [ :each | each notNil ] > thenCollect: [ :each | each class -> each size ] > > There's another source of sluggishness though. The input is only processed > at every 10 milliseconds (actually more rarely, because there's at least 10 > ms delay between input processing). > If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 > feels more responsive. > Btw it would be better to use the input semaphore instead of polling for > events, like Squeak does it. I wonder why was it changed. > > > Levente > >> >> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Henrik Sperre Johansen
On Sun, 17 Oct 2010, Henrik Johansen wrote:
> > > Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>: > >> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. >> >> >> Levente > It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. I see. But MessageTally doesn't: MessageTally spyAllOn: [ 10 seconds asDelay wait ] Squeak: **Leaves** 99.7% {9970ms} ProcessorScheduler class>>idleProcess Pharo: **Leaves** 89.9% {8990ms} ProcessorScheduler class>>idleProcess 10.1% {1010ms} Delay>>wait > > If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Okay, so the windows VM doesn't signal the semaphore. It could/should still be used at least on other platforms. A mixed system is also possible, because one can wait for a semaphore signal with a timeout. So for windows the timeout can be 10ms, while on other platforms 1000ms. Also waiting for 10ms, no matter how long the event processing took is a bad idea IMHO. Waiting for a total 10ms (which includes the time spent during processing the events) results in a more responsive system. Btw why doesn't the windows VM signal the semaphore? Levente > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Speeding up Pharo 1.1
|
|
http://forum.world.st/InputSemaphore-on-Windows-td1934394.html#a2014576 Basically, there may or may not be some issue with them not being noticed in the image, it hasn't been a priority since the Squeak image doesn't depend on it, and no-one have set aside the time to fix it. Not very hard really, just time-consuming and tedious checking you've hit all the points it has to be signalled. Cheers, Henry |
|
|
In reply to this post by Levente Uzonyi-2
I don't know why the Windows VM does not signal the semaphore. There are, of course, good and bad possible reasons why that might be.
The up side includes possible motives of compensating for weirdness in the Windows event queue over the many versions. Dolphin tries to be correct about it, and it took some effort; arguments could be made that they failed to get it right across all platforms (I recall having troubles with COM servers failing to run at times with the default event loop); OA dropped official support for Win2k years before that was appropriate (if it is even now), and the message queue appeared to be at the center of it. Correct me if I'm missing a combination of versions, but every time I have tried an old Squeak image and a modern vm on any old version of Windows I happened to have handy, dragging time image onto the vm worked. The bad part of waiting with a timeout is that the system runs (good) even when it is not properly managing the message queue, masking the problem (bad). As Levente suggets, one way to react to this is to ensure that the Linux and Mac vms do not need the timeout. ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]] Sent: Sunday, October 17, 2010 12:17 PM To: [hidden email] Subject: Re: [Pharo-project] Speeding up Pharo 1.1 On Sun, 17 Oct 2010, Henrik Johansen wrote: > > > Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>: > >> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. >> >> >> Levente > It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. I see. But MessageTally doesn't: MessageTally spyAllOn: [ 10 seconds asDelay wait ] Squeak: **Leaves** 99.7% {9970ms} ProcessorScheduler class>>idleProcess Pharo: **Leaves** 89.9% {8990ms} ProcessorScheduler class>>idleProcess 10.1% {1010ms} Delay>>wait > > If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Okay, so the windows VM doesn't signal the semaphore. It could/should still be used at least on other platforms. A mixed system is also possible, because one can wait for a semaphore signal with a timeout. So for windows the timeout can be 10ms, while on other platforms 1000ms. Also waiting for 10ms, no matter how long the event processing took is a bad idea IMHO. Waiting for a total 10ms (which includes the time spent during processing the events) results in a more responsive system. Btw why doesn't the windows VM signal the semaphore? Levente > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |