Speeding up Pharo 1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Speeding up Pharo 1.1

Bart Veenstra
Hi list,

I have been working with Pharo for almost a month now, and I suspect
that the performance is degrading fast. UI tasks takes several seconds
to react to my keyboard.

At work we use VAST and I have experience with VW as well and those
smalltaks react to my keyboard and mouse actions instantly. But Pharo
works very sluggish.

My image is about 130MB because I have loaded all dutch postcode in
memory, but that should not affect the performance of general
operations like typing with the keyboard. I am not a fast typer, but
sometimes it takes seconds to show my keyboard input. I can't use the
down key to select the right method from suggestions, because it seems
to lockup completely.

Are there ways to speedup Pharo? I would love to use cogVM but I
haven't got gemtools working on it...

Will upgrading to 1.1.1 fix these issues?

Is my OS (Windows 7-64bit) causing these issues?

Regards,

Bart

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Sven Van Caekenberghe
Bart,

On 16 Oct 2010, at 13:48, Bart Veenstra wrote:

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

I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues.
You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/).
In a large/old image, there could be lots of issues, of course.

HTH,

Sven




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Nicolas Cellier
I can feel this slugginess too, and we should fix that for good.

A clue: in Squeak trunk, here are the VM stats:
uptime 0h7m59s
memory 59,647,648 bytes
        old 48,744,032 bytes (81.7%)
        young 545,352 bytes (0.9%)
        used 49,289,384 bytes (82.6%)
        free 10,358,264 bytes (17.4%)
GCs 288 (1665ms between GCs)
        full 0 totalling 0ms (0.0% uptime)
        incr 288 totalling 486ms (0.0% uptime), avg 2.0ms
        tenures 15 (avg 19 GCs/tenure)
Since last view -7,895
        uptime 71.2s
        full -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms
        incr -7880 totalling -1,952ms (-3.0% uptime), avg
        tenures -548 (avg 14 GCs/tenure)

In Pharo:
uptime 0h6m48s
memory 29,690,612 bytes
        old 25,210,060 bytes (84.9%)
        young 252,096 bytes (0.8%)
        used 25,462,156 bytes (85.80000000000001%)
        free 4,228,456 bytes (14.200000000000001%)
GCs 4,969 (82ms between GCs)
        full 3 totalling 834ms (0.2% uptime), avg 278.0ms
        incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms
        tenures 75 (avg 66 GCs/tenure)
Since last view 4,777 (85ms between GCs)
        uptime 404.5s
        full 1 totalling -285ms (-0.1% uptime), avg -285.0ms
        incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms
        tenures 75 (avg 63 GCs/tenure)

A GC every 82ms, 20x+ more GC than trunk... Something is going wrong.
Could it be object creation at each event or something like that?

Nicolas

2010/10/16 Sven Van Caekenberghe <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Schwab,Wilhelm K
In reply to this post by Sven Van Caekenberghe
Bart,

My image is 40 MB right now.  That means you have about 100 MB of data?  How do you store it?  How many objects are there?  Are they of fixed size?  If so, you might try a quick experiment using a String or ByteArray wrapped with something that knows how to find a given code.  You might be putting a pretty good load on the GC and using a blob to hold the data might help.  I'm not sure where we are with respect to having a generational GC that would tenure and shrug off old objects.

IIRC, Alan Kay reported having a 160 MB Squeak image for demos, but that was many versions ago, so I hesitate to draw any comparisons.  If you can find or get a copy of it, it might be interesting to open it in current VM to see how it performs.

Syntax highlighting is a possible offender, though I would not expect delays like you are describing.  Do you by chance access the image over a remote desktop connection?  Do you notice the problem with only certain methods?

What do you see in Tools|Process Browser?  If you have a large number or processes running, it might explain a lot.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]]
Sent: Saturday, October 16, 2010 8:24 AM
To: [hidden email]
Subject: Re: [Pharo-project] Speeding up Pharo 1.1

Bart,

On 16 Oct 2010, at 13:48, Bart Veenstra wrote:

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

I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues.
You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/).
In a large/old image, there could be lots of issues, of course.

HTH,

Sven




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Bart Veenstra
Before I started loading all the postcodes in the system, the image
was about 80 MB. after loading all the postcodes it was about 108MB.

Stuff I have loaded:
Seaside (Complete)
JQWidgetBox
GemTools
SqeaukSSL
WebClient
XMLSupport
MockGemstone
SqueakDBX
MySQL
CSV
Query Extensions

and my own projects.

Looks like a typical image for me :)

For the postcode lookup system, i have 397024 streets, (inst vars:
city postcode name low high even latitude longitude), 9396 cities and
12 provinces. Not a complex model. They all are stored in
IdentityBags. Indexes will be maintained by GemStone in the future,
but for now I retrieve the address using:
self streets select: [:each | each postcode = postcode ].

How do I get the output from the process browser in text?

 I only have about 13 processes where the input events fetching
process takes about 30 procent and the rest is idle.

Regards,

Bart




2010/10/16 Schwab,Wilhelm K <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Schwab,Wilhelm K
In reply to this post by Nicolas Cellier
Are those negative numbers in the Squeak stats?



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Nicolas Cellier [[hidden email]]
Sent: Saturday, October 16, 2010 9:37 AM
To: [hidden email]
Subject: Re: [Pharo-project] Speeding up Pharo 1.1

I can feel this slugginess too, and we should fix that for good.

A clue: in Squeak trunk, here are the VM stats:
uptime                  0h7m59s
memory                  59,647,648 bytes
        old                     48,744,032 bytes (81.7%)
        young           545,352 bytes (0.9%)
        used            49,289,384 bytes (82.6%)
        free            10,358,264 bytes (17.4%)
GCs                             288 (1665ms between GCs)
        full                    0 totalling 0ms (0.0% uptime)
        incr            288 totalling 486ms (0.0% uptime), avg 2.0ms
        tenures         15 (avg 19 GCs/tenure)
Since last view -7,895
        uptime          71.2s
        full                    -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms
        incr            -7880 totalling -1,952ms (-3.0% uptime), avg
        tenures         -548 (avg 14 GCs/tenure)

In Pharo:
uptime                  0h6m48s
memory                  29,690,612 bytes
        old                     25,210,060 bytes (84.9%)
        young           252,096 bytes (0.8%)
        used            25,462,156 bytes (85.80000000000001%)
        free            4,228,456 bytes (14.200000000000001%)
GCs                             4,969 (82ms between GCs)
        full                    3 totalling 834ms (0.2% uptime), avg 278.0ms
        incr            4966 totalling 6,280ms (1.5% uptime), avg 1.3ms
        tenures         75 (avg 66 GCs/tenure)
Since last view 4,777 (85ms between GCs)
        uptime          404.5s
        full                    1 totalling -285ms (-0.1% uptime), avg -285.0ms
        incr            4776 totalling 6,088ms (1.5% uptime), avg 1.3ms
        tenures         75 (avg 63 GCs/tenure)

A GC every 82ms, 20x+ more GC than trunk... Something is going wrong.
Could it be object creation at each event or something like that?

Nicolas

2010/10/16 Sven Van Caekenberghe <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Igor Stasenko
In reply to this post by Nicolas Cellier
Something produces too much garbage.
It could be anything.
But most of the times, the cause of sluggines is finalization process.

On 16 October 2010 16:37, Nicolas Cellier
<[hidden email]> wrote:

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Mariano Martinez Peck
Just by cursious, could you do a SpaceTally new printSpaceAnalysis
and attach the generated file STspace.text

In addition, you could do some cleaning, at least to decrease the size of the image.
You can try to do "ScriptLoader new cleanUpForRelease"

Let us know

Mariano

On Sat, Oct 16, 2010 at 7:46 PM, Igor Stasenko <[hidden email]> wrote:
Something produces too much garbage.
It could be anything.
But most of the times, the cause of sluggines is finalization process.

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Eliot Miranda-2
In reply to this post by Nicolas Cellier
Hi Bart, Nicolas,

    Bart, are you using the standard VM or Cog?

    Nicolas, if this is the standard VM then do the two images have the same value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)?  If not, that could account for the difference in incremental GC frequency (in Cog the IGC trigger mechanism is different, based on space allocated not allocation count).


HTH
Eliot

On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier <[hidden email]> wrote:
I can feel this slugginess too, and we should fix that for good.

A clue: in Squeak trunk, here are the VM stats:
uptime                  0h7m59s
memory                  59,647,648 bytes
       old                     48,744,032 bytes (81.7%)
       young           545,352 bytes (0.9%)
       used            49,289,384 bytes (82.6%)
       free            10,358,264 bytes (17.4%)
GCs                             288 (1665ms between GCs)
       full                    0 totalling 0ms (0.0% uptime)
       incr            288 totalling 486ms (0.0% uptime), avg 2.0ms
       tenures         15 (avg 19 GCs/tenure)
Since last view -7,895
       uptime          71.2s
       full                    -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms
       incr            -7880 totalling -1,952ms (-3.0% uptime), avg
       tenures         -548 (avg 14 GCs/tenure)

In Pharo:
uptime                  0h6m48s
memory                  29,690,612 bytes
       old                     25,210,060 bytes (84.9%)
       young           252,096 bytes (0.8%)
       used            25,462,156 bytes (85.80000000000001%)
       free            4,228,456 bytes (14.200000000000001%)
GCs                             4,969 (82ms between GCs)
       full                    3 totalling 834ms (0.2% uptime), avg 278.0ms
       incr            4966 totalling 6,280ms (1.5% uptime), avg 1.3ms
       tenures         75 (avg 66 GCs/tenure)
Since last view 4,777 (85ms between GCs)
       uptime          404.5s
       full                    1 totalling -285ms (-0.1% uptime), avg -285.0ms
       incr            4776 totalling 6,088ms (1.5% uptime), avg 1.3ms
       tenures         75 (avg 63 GCs/tenure)

A GC every 82ms, 20x+ more GC than trunk... Something is going wrong.
Could it be object creation at each event or something like that?

Nicolas

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Nicolas Cellier
2010/10/16 Eliot Miranda <[hidden email]>:

> Hi Bart, Nicolas,
>     Bart, are you using the standard VM or Cog?
>     Nicolas, if this is the standard VM then do the two images have the same
> value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)?  If not, that
> could account for the difference in incremental GC frequency (in Cog the IGC
> trigger mechanism is different, based on space allocated not allocation
> count).
>
> HTH
> Eliot

Oh, comparison was not fair, I ran Squeak with COG.
When I try COG+Pharo, some updates are missing, I can't print the VMstats.

Nicolas

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Nicolas Cellier
2010/10/16 Nicolas Cellier <[hidden email]>:

> 2010/10/16 Eliot Miranda <[hidden email]>:
>> Hi Bart, Nicolas,
>>     Bart, are you using the standard VM or Cog?
>>     Nicolas, if this is the standard VM then do the two images have the same
>> value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)?  If not, that
>> could account for the difference in incremental GC frequency (in Cog the IGC
>> trigger mechanism is different, based on space allocated not allocation
>> count).
>>
>> HTH
>> Eliot
>
> Oh, comparison was not fair, I ran Squeak with COG.
> When I try COG+Pharo, some updates are missing, I can't print the VMstats.
>
> Nicolas
>

Well, I mean in #spyAllEvery:on:

Nicolas

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Bart Veenstra
In reply to this post by Mariano Martinez Peck
While doing the SpaceTally new printSpaceAnalysis my image is locking
up. Looked like it would take some time, so started playing Medal of
Honor (recommend it!!)

Anyhow.. Back in Pharo I have a WARNING, Event buffer overflow in the
bottom...anyway to repair this without closing the image?

2010/10/16 Mariano Martinez Peck <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Levente Uzonyi-2
In reply to this post by Bart Veenstra
On Sat, 16 Oct 2010, Bart Veenstra wrote:

> Hi list,
>
> I have been working with Pharo for almost a month now, and I suspect
> that the performance is degrading fast. UI tasks takes several seconds
> to react to my keyboard.

That kind of sluggishness is probably related to finalization/gc. Please
send us the result of the following expression:

(WeakArray classPool at: #FinalizationDependents)
  select: [ :each | each notNil ]
  thenCollect: [ :each | each class -> each size ]

There's another source of sluggishness though. The input is only processed
at every 10 milliseconds (actually more rarely, because there's at least
10 ms delay between input processing).
If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo
1.1 feels more responsive.
Btw it would be better to use the input semaphore instead of polling for
events, like Squeak does it. I wonder why was it changed.


Levente

>
> At work we use VAST and I have experience with VW as well and those
> smalltaks react to my keyboard and mouse actions instantly. But Pharo
> works very sluggish.
>
> My image is about 130MB because I have loaded all dutch postcode in
> memory, but that should not affect the performance of general
> operations like typing with the keyboard. I am not a fast typer, but
> sometimes it takes seconds to show my keyboard input. I can't use the
> down key to select the right method from suggestions, because it seems
> to lockup completely.
>
> Are there ways to speedup Pharo? I would love to use cogVM but I
> haven't got gemtools working on it...
>
> Will upgrading to 1.1.1 fix these issues?
>
> Is my OS (Windows 7-64bit) causing these issues?
>
> Regards,
>
> Bart
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
Can you check in 1.2 because I seem to remember that it was fixed?

TX

On Oct 16, 2010, at 8:51 PM, Nicolas Cellier wrote:

> Oh, comparison was not fair, I ran Squeak with COG.
> When I try COG+Pharo, some updates are missing, I can't print the VMstats.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Stéphane Ducasse
In reply to this post by Bart Veenstra

On Oct 17, 2010, at 12:37 AM, Levente Uzonyi wrote:

> On Sat, 16 Oct 2010, Bart Veenstra wrote:
>
>> Hi list,
>>
>> I have been working with Pharo for almost a month now, and I suspect
>> that the performance is degrading fast. UI tasks takes several seconds
>> to react to my keyboard.
>
> That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression:
>
> (WeakArray classPool at: #FinalizationDependents)
> select: [ :each | each notNil ]
> thenCollect: [ :each | each class -> each size ]
>
> There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing).
> If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive.
> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed.


The idea was to remove the poll behavior
now I do not remember if the semaphore was removed or simply was waiting for the windows vm to get the support and was forgotten.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Henrik Sperre Johansen
In reply to this post by Levente Uzonyi-2


Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>:

> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed.
>
>
> Levente
It doesn't, there's effectively polling done in the UI threads hand processing on Squeak.

If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Igor Stasenko
In reply to this post by Levente Uzonyi-2
On 17 October 2010 01:37, Levente Uzonyi <[hidden email]> wrote:

> On Sat, 16 Oct 2010, Bart Veenstra wrote:
>
>> Hi list,
>>
>> I have been working with Pharo for almost a month now, and I suspect
>> that the performance is degrading fast. UI tasks takes several seconds
>> to react to my keyboard.
>
> That kind of sluggishness is probably related to finalization/gc. Please
> send us the result of the following expression:
>
> (WeakArray classPool at: #FinalizationDependents)
>        select: [ :each | each notNil ]
>        thenCollect: [ :each | each class -> each size ]
>
> There's another source of sluggishness though. The input is only processed
> at every 10 milliseconds (actually more rarely, because there's at least 10
> ms delay between input processing).
> If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1
> feels more responsive.
> Btw it would be better to use the input semaphore instead of polling for
> events, like Squeak does it. I wonder why was it changed.
>
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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Levente Uzonyi-2
In reply to this post by Henrik Sperre Johansen
On Sun, 17 Oct 2010, Henrik Johansen wrote:

>
>
> Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>:
>
>> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed.
>>
>>
>> Levente
> It doesn't, there's effectively polling done in the UI threads hand processing on Squeak.

I see. But MessageTally doesn't:

MessageTally spyAllOn: [ 10 seconds asDelay wait ]

Squeak:
**Leaves**
99.7% {9970ms} ProcessorScheduler class>>idleProcess

Pharo:
**Leaves**
89.9% {8990ms} ProcessorScheduler class>>idleProcess
10.1% {1010ms} Delay>>wait

>
> If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it.

Okay, so the windows VM doesn't signal the semaphore. It could/should
still be used at least on other platforms.
A mixed system is also possible, because one can wait for a semaphore
signal with a timeout. So for windows the timeout can be 10ms, while on
other platforms 1000ms.

Also waiting for 10ms, no matter how long the event processing took is a
bad idea IMHO. Waiting for a total 10ms (which includes the time spent
during processing the events) results in a more responsive system.

Btw why doesn't the windows VM signal the semaphore?


Levente

>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Henrik Sperre Johansen
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
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up Pharo 1.1

Schwab,Wilhelm K
In reply to this post by Levente Uzonyi-2
I don't know why the Windows VM does not signal the semaphore.  There are, of course, good and bad possible reasons why that might be.  

The up side includes possible motives of compensating for weirdness in the Windows event queue over the many versions.  Dolphin tries to be correct about it, and it took some effort; arguments could be made that they failed to get it right across all platforms (I recall having troubles with COM servers failing to run at times with the default event loop); OA dropped official support for Win2k years before that was appropriate (if it is even now), and the message queue appeared to be at the center of it.  Correct me if I'm missing a combination of versions, but every time I have tried an old Squeak image and a modern vm on any old version of Windows I happened to have handy, dragging time image onto the vm worked.

The bad part of waiting with a timeout is that the system runs (good) even when it is not properly managing the message queue, masking the problem (bad).  As Levente suggets, one way to react to this is to ensure that the Linux and Mac vms do not need the timeout.



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]]
Sent: Sunday, October 17, 2010 12:17 PM
To: [hidden email]
Subject: Re: [Pharo-project] Speeding up Pharo 1.1

On Sun, 17 Oct 2010, Henrik Johansen wrote:

>
>
> Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[hidden email]>:
>
>> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed.
>>
>>
>> Levente
> It doesn't, there's effectively polling done in the UI threads hand processing on Squeak.

I see. But MessageTally doesn't:

MessageTally spyAllOn: [ 10 seconds asDelay wait ]

Squeak:
**Leaves**
99.7% {9970ms} ProcessorScheduler class>>idleProcess

Pharo:
**Leaves**
89.9% {8990ms} ProcessorScheduler class>>idleProcess
10.1% {1010ms} Delay>>wait

>
> If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it.

Okay, so the windows VM doesn't signal the semaphore. It could/should
still be used at least on other platforms.
A mixed system is also possible, because one can wait for a semaphore
signal with a timeout. So for windows the timeout can be 10ms, while on
other platforms 1000ms.

Also waiting for 10ms, no matter how long the event processing took is a
bad idea IMHO. Waiting for a total 10ms (which includes the time spent
during processing the events) results in a more responsive system.

Btw why doesn't the windows VM signal the semaphore?


Levente

>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
123