[Pharo-project] Making some progress, and a few observations
Hello all, I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked. Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package? It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages? The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported. Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long, and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little. Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price. Bill
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another. Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up. Saving an image is not necessarily quick either, I _think_ particuarly on Linux?? Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
Stef, No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit-virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick. This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal. In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right. A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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 Wed, Jul 15, 2009 at 7:34 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit-virus software
Nod32 in Windows WON'T let you use squeak or Pharo. You have to exclude from Nod32 the folder where you have the .changes.
and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Bill, Could you post the results of the following benchmark? 0 tinyBenchmarks This basically measures how many bytecodes and messages the VM can execute per second. Maybe that helps us to put your experience in relation to the VM and hardware speed. On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: '543236074 bytecodes/sec; 12101592 sends/sec' Cheers, Adrian On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
Alain, I'll reply twice vs. gluing these together. Here, I have remoted to an XP machine, but hopefully that won't clobber the benchmark (if it does, I can repeat it later): '141828254 bytecodes/sec; 6938144 sends/sec' Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec Sent: Wednesday, July 15, 2009 5:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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 my crusty old Linux box: 155339805 bytecodes/sec; 3931964 sends/sec However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
Sounds like your machine is 4 times slower than ours. which is good we should all have machine like that to make pharo fast On Jul 16, 2009, at 3:07 AM, Schwab,Wilhelm K wrote:
On my crusty old Linux box:
155339805 bytecodes/sec; 3931964 sends/sec
However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec'
not so bad with linux :)
Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
Stef, Thanks for looking at it that way. I would not bother you with this box if it were hopelessly slow. One common thing that keeps me using it is going on as I type: I'm using a remote desktop client to access a an xp machine in my office, and this broken down old plug does this better than it handles editing in Pharo. We have some room for improvement, and this box is available for benchamarking as needed. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, July 16, 2009 4:27 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Sounds like your machine is 4 times slower than ours. which is good we should all have machine like that to make pharo fast On Jul 16, 2009, at 3:07 AM, Schwab,Wilhelm K wrote:
On my crusty old Linux box:
155339805 bytecodes/sec; 3931964 sends/sec
However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec'
not so bad with linux :)
Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In the Windows camp, Watery2 theme... Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371. 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373 Older laptop, XP, 1GB, Pentium M (1.73 GHz)... 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677 Still feels quite responsive even on that! Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <alain.plantec@free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations On my crusty old Linux box: 155339805 bytecodes/sec; 3931964 sends/sec However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
If that helps... 0 tinyBenchmarks Windows XP, 2002, SP3 Pentium 4, dual core, 3Ghz, 2 Gb RAM All tests were run 5 times and here are the averages : Some comparisons: Squeak 3.9 latest update: #7067 76297334 bytecodes/sec; 3397437 sends/sec Squeak 3.10.2 latest update: #7179 74839234 bytecodes/sec; 3443964 sends/sec Pharo 0.1 latest update: #10377 75877223 bytecodes/sec; 3134820 sends/sec ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Gary Chambers <gazzaguru2@btinternet.com> To: Pharo-project@lists.gforge.inria.fr Sent: Thursday, July 16, 2009 6:51:59 AM Subject: Re: [Pharo-project] Making some progress, and a few observations In the Windows camp, Watery2 theme... Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371. 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373 Older laptop, XP, 1GB, Pentium M (1.73 GHz)... 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677 Still feels quite responsive even on that! Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <alain.plantec@free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations On my crusty old Linux box: 155339805 bytecodes/sec; 3931964 sends/sec However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' not so bad with linux :) Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com
Pentium 4 2.26 GZ, windows XP SP3, 2GB RAM 168199737 bytecodes/sec; 3670275 sends/sec 2009/7/16 Benoit St-Jean <bstjean@yahoo.com>
If that helps...
0 tinyBenchmarks
Windows XP, 2002, SP3 Pentium 4, dual core, 3Ghz, 2 Gb RAM
All tests were run 5 times and here are the averages :
Some comparisons:
Squeak 3.9 latest update: #7067 76297334 bytecodes/sec; 3397437 sends/sec
Squeak 3.10.2 latest update: #7179 74839234 bytecodes/sec; 3443964 sends/sec
Pharo 0.1 latest update: #10377 75877223 bytecodes/sec; 3134820 sends/sec
----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ *From:* Gary Chambers <gazzaguru2@btinternet.com> *To:* Pharo-project@lists.gforge.inria.fr *Sent:* Thursday, July 16, 2009 6:51:59 AM
*Subject:* Re: [Pharo-project] Making some progress, and a few observations
In the Windows camp, Watery2 theme...
Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371.
0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec'
Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373
Older laptop, XP, 1GB, Pentium M (1.73 GHz)...
0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec'
Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677
Still feels quite responsive even on that!
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <alain.plantec@free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations
On my crusty old Linux box:
155339805 bytecodes/sec; 3931964 sends/sec
However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec'
not so bad with linux :)
Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! *Get it Now for Free! *<http://downloads.yahoo.com/ca/internetexplorer/>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Here are my numbers. Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) OS: Windows XP SP3 Seaside 2.8.3 One Click Image: '157248157 bytecodes/sec; 4708854 sends/sec' Seaside 2.8.4 One Click Image: '158907510 bytecodes/sec; 4592283 sends/sec' pharo0.1-10373web09.07.2: '156479217 bytecodes/sec; 4413998 sends/sec' Regards, Esteban A. Maringolo
I think it has no sense to test with several images. Look adrian comment "This basically measures how many bytecodes and messages the VM can execute per second." So, I guess it is a benchmark for VM + hardware. I don't think the image can influence much here. Am I correct? best, Mariano On Thu, Jul 16, 2009 at 1:38 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Here are my numbers. Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) OS: Windows XP SP3
Seaside 2.8.3 One Click Image: '157248157 bytecodes/sec; 4708854 sends/sec'
Seaside 2.8.4 One Click Image: '158907510 bytecodes/sec; 4592283 sends/sec'
pharo0.1-10373web09.07.2: '156479217 bytecodes/sec; 4413998 sends/sec'
Regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I remember (a long time ago) digging around for a computer to test one of the large commercial Smalltalks - VA IIRC. It did not go well, and in the process of checking on how the machine performed otherwise, I ran something out of the then-current M$ Office and quickly discovered that the particular machine was not up to my needs. The thing just crawled, and the interesting part was watching it draw, several times(!!), one of the common dialogs. It was quite a display of inefficiency, and was repeated with every user interaction on that dialot. The point being that faster machines were able to overpower the bad code, which is pretty much what has kept MS in business. Byte codes and message sends are important, but so is efficiency and feedback to the user. ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Thursday, July 16, 2009 9:46 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations I think it has no sense to test with several images. Look adrian comment "This basically measures how many bytecodes and messages the VM can execute per second." So, I guess it is a benchmark for VM + hardware. I don't think the image can influence much here. Am I correct? best, Mariano On Thu, Jul 16, 2009 at 1:38 PM, Esteban A. Maringolo <emaringolo@gmail.com<mailto:emaringolo@gmail.com>> wrote: Here are my numbers. Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) OS: Windows XP SP3 Seaside 2.8.3 One Click Image: '157248157 bytecodes/sec; 4708854 sends/sec' Seaside 2.8.4 One Click Image: '158907510 bytecodes/sec; 4592283 sends/sec' pharo0.1-10373web09.07.2: '156479217 bytecodes/sec; 4413998 sends/sec' Regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/7/16 Mariano Martinez Peck <marianopeck@gmail.com>:
I think it has no sense to test with several images. Look adrian comment
"This basically measures how many bytecodes and messages the VM can execute per second."
So, I guess it is a benchmark for VM + hardware. I don't think the image can influence much here. Am I correct?
Oookay, sorry. However, I understand the 2.8.3 one-click and 2.8.4 one click have different VM's. With the latest pharo-web, with NOD32 antivirus disabled, the speed up was pretty significant. Regards, -- Esteban
On Thu, Jul 16, 2009 at 2:12 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
With the latest pharo-web, with NOD32 antivirus disabled, the speed up was pretty significant.
yes. Nod32 WON'T let you use Squeak, Pharo, Quis or whatever. You can notice this when you use monticello. As the .changes is being changed a lot, nod32 is inspecting it all the time.....unusable. Solution: exclude the directory where the .changes is fron Nod32 configuration!
Regards,
-- Esteban
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We should pay attention that there is closure in pharo. On Jul 16, 2009, at 3:44 PM, Benoit St-Jean wrote:
If that helps...
0 tinyBenchmarks
Windows XP, 2002, SP3 Pentium 4, dual core, 3Ghz, 2 Gb RAM
All tests were run 5 times and here are the averages :
Some comparisons:
Squeak 3.9 latest update: #7067 76297334 bytecodes/sec; 3397437 sends/sec
Squeak 3.10.2 latest update: #7179 74839234 bytecodes/sec; 3443964 sends/sec
Pharo 0.1 latest update: #10377 75877223 bytecodes/sec; 3134820 sends/sec
----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
From: Gary Chambers <gazzaguru2@btinternet.com> To: Pharo-project@lists.gforge.inria.fr Sent: Thursday, July 16, 2009 6:51:59 AM Subject: Re: [Pharo-project] Making some progress, and a few observations
In the Windows camp, Watery2 theme...
Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), Pharo0.1Core-10371.
0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec'
Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 373
Older laptop, XP, 1GB, Pentium M (1.73 GHz)...
0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec'
Time millisecondsToRun: [ Browser fullOnClass: Object selector: #at:. World displayWorld] 677
Still feels quite responsive even on that!
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <alain.plantec@free.fr> Sent: Thursday, July 16, 2009 2:07 AM Subject: Re: [Pharo-project] Making some progress, and a few observations
On my crusty old Linux box:
155339805 bytecodes/sec; 3931964 sends/sec
However, I always like to test on less than my customers will have, so by some arguments, this machine is just about right.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@free.fr] Sent: Wednesday, July 15, 2009 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Adrian Lienhard a écrit :
Bill,
Could you post the results of the following benchmark?
0 tinyBenchmarks
On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get:
'543236074 bytecodes/sec; 12101592 sends/sec'
On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec'
not so bad with linux :)
Cheers Alain
Cheers, Adrian
On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote:
Stef,
No browser should be that slow. I suspect the Linux vm is not a speed demon, the xp machines I use are heavily burdened by anit- virus software and other performance drains, etc. My linux box at home might be further hindered by the fact that I bought a wide screen monitor for it, and use LOTS of screen real estate. Still, when I compare Pharo with other software (including Dolphin) under similarly abusive conditions, Pharo is not quick.
This particular image is small; it is based on the most recent web image, and is 22 MB. It has some of my Seaside code in it, but has not yet executed same. I have a couple of Seaside cleanup expressions that help when images bloat up, but looking at the current size makes me think I'm missing an opportunity. All that aside, on my linux box, I find that after the saving cursor disappears, it can take a few seconds for the image to again become responsive. On xp in my office, there is at least a second of down time after the cursor reverts to normal.
In doing some SIF imports, I noted that it was hard to tell when the image was still busy. I have no idea how long it should take to do the work it was doing, but it took long enough that some gentle prodding becomes irresistable: "is it done yet?" I remember lots of debate about Cursor class>>showWhile: on Dolphin; it might be one of those things that is tricky to get right.
A little bit nicer news: I have it running on my office machine (xp), with FreeType in use, and it's ok with the standard tools and the w2k theme.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
Stef,
In terms of response times, even with a lot of things turned off, I was still surprised at how long it takes to change from even one method to another.
which browser are you using. Because the old browser should not be that slow.
Anything past 0.2 sec (or whatever that threshold is) starts to add up; Pharo sometimes takes up to a second, which is _really_ shows up.
Saving an image is not necessarily quick either, I _think_ particuarly on Linux??
What is the size of your image: here jannik generated an image of 800 mb.
Also, I get the sense the wait cursors are displayed, on Linux, for a smaller fraction of the down time than on Windows.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 15, 2009 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations
On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote:
Hello all,
I managed to create an install script; as I suspected would be case, it was very anticlimactic. I tried creating a password-protected directory under my personal web site, but that did not go well. The authentication is weird, so it was probably asking a lot. A directory repository worked.
Good to know
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package?
normally it should.
It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it. Do any of you script saving your packages?
you can check in ScriptLoader to see how we compute the packages that changed (not only dirty but also new packages)
The results are untested at present, but I used SIF to transfer a fair amount of code into Pharo. To cope with the naming of the ODBC classes, I ended up doing things like Smalltalk at:#DBConnection put:ODBCConnection, and that worked out nicely, at least AFAICT at this stage. SIF finally ended up complaining about running out of items when processing the last file. I reserve the right to later report that it was a miserable failure, but it looks like I most of the code imported.
Using the standard tools, the w2k theme, disabling faded backgrounds and enabling fast drag, performance on an older Linux system is ok (more or less). There are still things that take too long,
like what?
and Pharo's responses are no better (sometimes worse) than even software running over a remote desktop connection. We need a speed boost, but judicious settings help a little.
Is there a way to disable the anti-aliased fonts? In fairness, I should try turning that off to see if any speed boost is worth the price.
Bill
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Does Monticello/PackageInfo see a change in method category (aka package) as a change to the package? Â It appears not, and it worries me a little in that it seems to make it easy to lose work by forgetting to save it.
The MCWorkingCopy class is notified about changes in the system and marks the involved packages as dirty. Normally that works well.
Do any of you script saving your packages?
In Seaside 2.9 consists of 72 packages. In the class WADevelopment we created a couple of scripts to update, diff, merge and commit all packages at once. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (9)
-
Adrian Lienhard -
Alain Plantec -
Benoit St-Jean -
Esteban A. Maringolo -
Gary Chambers -
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse