[Pharo-project] Speeding up Pharo 1.1
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
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
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Are those negative numbers in the Squeak stats? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Saturday, October 16, 2010 9:37 AM To: Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/16 Eliot Miranda <eliot.miranda@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/16 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/10/16 Eliot Miranda <eliot.miranda@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Saturday, October 16, 2010 8:24 AM To: Pharo-project@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@lists.gforge.inria.fr 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 <bschwab@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Saturday, October 16, 2010 8:24 AM To: Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves@elte.hu>:
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
On Sun, 17 Oct 2010, Henrik Johansen wrote:
Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves@elte.hu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente Uzonyi-2 wrote:
Btw why doesn't the windows VM signal the semaphore?
Levente
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 -- View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 October 2010 21:45, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Levente Uzonyi-2 wrote:
Btw why doesn't the windows VM signal the semaphore?
Levente
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.
I don't think that this is the problem with image being sluggy. It would feel sluggy from very beginning, not after you load a lots of stuff into image, isnt?
Cheers, Henry -- View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 17.10.2010 20:49, Igor Stasenko wrote:
On 17 October 2010 21:45, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Levente Uzonyi-2 wrote:
Btw why doesn't the windows VM signal the semaphore?
Levente
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.
I don't think that this is the problem with image being sluggy. It would feel sluggy from very beginning, not after you load a lots of stuff into image, isnt?
Yup, this was mainly to answer why Pharo doesn't use the InputSemaphore, a short detour which hopefully ends here. I don't have an image which has been running for 7 hours (non-core at least), and haven't experienced the slowdown reported myself, so didn't feel qualified to comment on that matter. Cheers, Henry
On Sun, 17 Oct 2010, Henrik Sperre Johansen wrote:
Levente Uzonyi-2 wrote:
Btw why doesn't the windows VM signal the semaphore?
Levente
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.
So someone has to do it and it will work. :) Waiting for the signal with a timeout can also tell if there's code in the vm that doesn't signal the semaphore. If the waiting ends because of the timeout, but there are new events available, then we can be pretty sure there's more VM code to be fixed. Levente
Cheers, Henry -- View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Sunday, October 17, 2010 12:17 PM To: Pharo-project@lists.gforge.inria.fr 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 <leves@elte.hu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17 October 2010 01:37, Levente Uzonyi <leves@elte.hu> 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.
because windows VM does not signaling input semaphore
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image... ((WeakArray classPool at: #FinalizationDependents) as: Array) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin) I don't understand yet, but I begin to gather clues why updating pharo goes so badly... Nicolas
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
(WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)}
I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like
(ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin)
I don't understand yet, but I begin to gather clues why updating pharo goes so badly...
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2010/10/18 Igor Stasenko <siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk: cachedDefinitions ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ] It would be worth a try in Pharo. Nicolas
(WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)}
I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like
(ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin)
I don't understand yet, but I begin to gather clues why updating pharo goes so badly...
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 October 2010 23:41, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/18 Igor Stasenko <siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions     ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
I disagree. Its not a simplification. Its a bug fix! :) Recently, i provided the similar thing for Pharo (didn't knew it was already fixed for Squeak): http://code.google.com/p/pharo/issues/detail?id=3048
Nicolas
-- Best regards, Igor Stasenko AKA sig.
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko <siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed. Levente
Nicolas
(WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)}
I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like
(ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin)
I don't understand yet, but I begin to gather clues why updating pharo goes so badly...
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/19 Levente Uzonyi <leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko <siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions     ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Levente
Nicolas
(WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)}
I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like
(ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin)
I don't understand yet, but I begin to gather clues why updating pharo goes so badly...
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 18.10.2010 23:21, Igor Stasenko wrote:
2010/10/19 Levente Uzonyi<leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko<siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi<leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370). This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo. IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards) Cheers, Henry
On 19 October 2010 00:30, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
 On 18.10.2010 23:21, Igor Stasenko wrote:
2010/10/19 Levente Uzonyi<leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko<siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Â wrote:
2010/10/17 Levente Uzonyi<leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> Â each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions     ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards)
it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them).
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 18.10.2010 23:43, Igor Stasenko wrote:
On 19 October 2010 00:30, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 18.10.2010 23:21, Igor Stasenko wrote:
2010/10/19 Levente Uzonyi<leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko<siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/17 Levente Uzonyi<leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370). This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo. IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards)
it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them).
Except, you know, if they're not registered for finalization at all, they're probably not meant to be finalized. Cheers, Henry
On Tue, 19 Oct 2010, Igor Stasenko wrote:
On 19 October 2010 00:30, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: Â On 18.10.2010 23:21, Igor Stasenko wrote:
2010/10/19 Levente Uzonyi<leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko<siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Â wrote:
2010/10/17 Levente Uzonyi<leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> Â each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions     ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards)
it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them). It's incorrect, because WeakKeyDictionaries are not designed to be accessed concurrently, but this can happen if the dictionary is registered to the finalization process. It's inefficient, because someone has to send #finalizeValues, even when there's no finalization action. Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/19 Levente Uzonyi <leves@elte.hu>:
On Tue, 19 Oct 2010, Igor Stasenko wrote:
On 19 October 2010 00:30, Henrik Sperre Johansen
<henrik.s.johansen@veloxit.no> wrote:
 On 18.10.2010 23:21, Igor Stasenko wrote:
2010/10/19 Levente Uzonyi<leves@elte.hu>:
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/18 Igor Stasenko<siguctua@gmail.com>:
On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Â wrote:
2010/10/17 Levente Uzonyi<leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) Â Â Â select: [ :each | each notNil ] Â Â Â thenCollect: [ :each | each class -> Â each size] -> {(WeakIdentityKeyDictionary->22370).
This is an MC cache. And major reason of image slowdown.
Levente did this simplification in trunk:
cachedDefinitions     ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary new ]
It would be worth a try in Pharo.
IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if they're not registered to the finalization process. So this won't work as long as that's not fixed.
Huh? Can you provide a code to show it? Test case please?
Just add lots of objects which will be GC'd to an unregistered WeakKeyDictionary. After X objects are gc'd, you'd still have X nil-keyed associations in the dictionary. Add Y objects, gc those, and you have X+Y nil-keys in the dict. (If dict grown/rehashed, all nicely placed index 1 onwards)
it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys before #finalizeValues could visit them).
It's incorrect, because WeakKeyDictionaries are not designed to be accessed concurrently, but this can happen if the dictionary is registered to the finalization process.
True. Another reason to not register them like MC in Pharo currently does.
It's inefficient, because someone has to send #finalizeValues, even when there's no finalization action.
That's why in my patch, i placed #finalizeValues on finishing package load/unload actions.
Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mon, 18 Oct 2010, Nicolas Cellier wrote:
2010/10/17 Levente Uzonyi <leves@elte.hu>:
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 ]
While updating pharo 1.2, after an EndOfCentralDirectory error, I got a very unresponsive image...
((WeakArray classPool at: #FinalizationDependents) as: Array) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size] -> {(WeakIdentityKeyDictionary->22370). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)}
I tried to inspect it 5 minutes ago, but hey, answer in another email... Ah, OK, cmd+shift+. just worked. I had to interrupt #finalizationProcess itself finally... Oh inspect is sorting the keys... unusable. So what's in the array ? Things like
(ScriptLoader>>#update12125 "a CompiledMethod(0)")->a MCMethodDefinition(ScriptLoader>>update12125) (PragmaCollector>>#release "a CompiledMethod(964689920)")->a MCMethodDefinition(PragmaCollector>>release) (Float>>#arcSin "a CompiledMethod(358088704)")->a MCMethodDefinition(Float>>arcSin)
I don't understand yet, but I begin to gather clues why updating pharo goes so badly...
IIRC Igor already checked that most of the time is spend in the finalization process and gc. Levente
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Bart, can you try doing: MCMethodDefinition shutDown in your image? On 16 October 2010 14:48, Bart Veenstra <bart.veenstra@gmail.com> 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S 2010/10/17 Igor Stasenko <siguctua@gmail.com>:
Bart, can you try doing:
MCMethodDefinition shutDown
in your image?
On 16 October 2010 14:48, Bart Veenstra <bart.veenstra@gmail.com> 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
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
VM Statistics: uptime 45h21m14s memory 125,787,076 bytes old 122,936,884 bytes (97.7%) young 288,944 bytes (0.2%) used 123,225,828 bytes (98.0%) free 2,561,248 bytes (2.0%) GCs 211,214 (773ms between GCs) full 26 totalling 9,392ms (0.0% uptime), avg 361.2ms incr 211188 totalling 6,751ms (0.0% uptime), avg 0.0ms tenures 176 (avg 1199 GCs/tenure) Since last view 198,425 (0ms between GCs) uptime -29.4s full 5 totalling 6,910ms (-23.5% uptime), avg 1382.0ms incr 198420 totalling 4,258ms (-14.5% uptime), avg 0.0ms tenures 100 (avg 1984 GCs/tenure) 2010/10/18 Bart Veenstra <bart.veenstra@gmail.com>:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
2010/10/17 Igor Stasenko <siguctua@gmail.com>:
Bart, can you try doing:
MCMethodDefinition shutDown
in your image?
On 16 October 2010 14:48, Bart Veenstra <bart.veenstra@gmail.com> 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
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 Oct 2010, at 09:21, Bart Veenstra wrote:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
That is what I had before, see my earlier answer... Sven
I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part. Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much. Regards, Bart 2010/10/18 Sven Van Caekenberghe <sven@beta9.be>:
On 18 Oct 2010, at 09:21, Bart Veenstra wrote:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
That is what I had before, see my earlier answer...
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. SIXX has done well for me so far with data. What don't you understand about loading? For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra@gmail.com] Sent: Monday, October 18, 2010 3:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part. Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much. Regards, Bart 2010/10/18 Sven Van Caekenberghe <sven@beta9.be>:
On 18 Oct 2010, at 09:21, Bart Veenstra wrote:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
That is what I had before, see my earlier answer...
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I haven't put my mind yet to loading the data, but I guess I will get this running pretty soon. For loading packages I will create a metacello configuratoin with all packages so I only need to load this once. (including seaside and other 3rd party tools) Regards, Bart 2010/10/18 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. Â SIXX has done well for me so far with data. Â What don't you understand about loading?
For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra@gmail.com] Sent: Monday, October 18, 2010 3:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1
I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part.
Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much.
Regards,
Bart
2010/10/18 Sven Van Caekenberghe <sven@beta9.be>:
On 18 Oct 2010, at 09:21, Bart Veenstra wrote:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
That is what I had before, see my earlier answer...
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I doubt you will have trouble loading with SIXX, but ask if you do :) ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra@gmail.com] Sent: Monday, October 18, 2010 7:54 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 I haven't put my mind yet to loading the data, but I guess I will get this running pretty soon. For loading packages I will create a metacello configuratoin with all packages so I only need to load this once. (including seaside and other 3rd party tools) Regards, Bart 2010/10/18 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. SIXX has done well for me so far with data. What don't you understand about loading?
For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra@gmail.com] Sent: Monday, October 18, 2010 3:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1
I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part.
Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much.
Regards,
Bart
2010/10/18 Sven Van Caekenberghe <sven@beta9.be>:
On 18 Oct 2010, at 09:21, Bart Veenstra wrote:
After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
That is what I had before, see my earlier answer...
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Oct 18, 2010 at 9:21 AM, Bart Veenstra <bart.veenstra@gmail.com>wrote:
After MCMethodDefinition shutDown
Does this have some kind of bad side effect or I can do it also? Cheers Mariano
it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
2010/10/17 Igor Stasenko <siguctua@gmail.com>:
Bart, can you try doing:
MCMethodDefinition shutDown
in your image?
On 16 October 2010 14:48, Bart Veenstra <bart.veenstra@gmail.com> 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
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/18 Mariano Martinez Peck <marianopeck@gmail.com>:
On Mon, Oct 18, 2010 at 9:21 AM, Bart Veenstra <bart.veenstra@gmail.com> wrote:
After MCMethodDefinition shutDown
Does this have some kind of bad side effect or I can do it also?
it clears the MC cache. Absolutely safe. See http://code.google.com/p/pharo/issues/detail?id=3048.. and there are also a recent discussion about it on pharo-dev about removing MC cache from weak-dependents list, (but i'm too lazy to search and give a link to it :) ).
Cheers
Mariano
it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S
2010/10/17 Igor Stasenko <siguctua@gmail.com>:
Bart, can you try doing:
MCMethodDefinition shutDown
in your image?
On 16 October 2010 14:48, Bart Veenstra <bart.veenstra@gmail.com> 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
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (10)
-
Bart Veenstra -
Eliot Miranda -
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
Levente Uzonyi -
Mariano Martinez Peck -
Nicolas Cellier -
Schwab,Wilhelm K -
Sven Van Caekenberghe