[Pharo-project] Pharo-Dev/web Image slowness
Hi, I recently downloaded the latest Pharo Dev and Web images, and also the 2.8.4 one-click (which seems to be based on the Pharo image and VM too). And I found out that its performance is terrible, it takes forever (you perceive the delay) to open a browser, browse senders, change a method selection on the OB or even do a "print-it" on a workspace. However when accessing seaside through the web UI, it's blazing fast. Which makes me think there is something which is not working as it should. As a side note, I downloaded the latest Cuis image from http://www.jvuletich.org/Cuis/Index.html, and its amazingly fast. ¿Am I missing something? Best regards, Esteban A. Maringolo
take the core image. The default tools in web dev are too slow right now. Stef On Jul 13, 2009, at 11:05 PM, Esteban A. Maringolo wrote:
Hi,
I recently downloaded the latest Pharo Dev and Web images, and also the 2.8.4 one-click (which seems to be based on the Pharo image and VM too).
And I found out that its performance is terrible, it takes forever (you perceive the delay) to open a browser, browse senders, change a method selection on the OB or even do a "print-it" on a workspace.
However when accessing seaside through the web UI, it's blazing fast. Which makes me think there is something which is not working as it should.
As a side note, I downloaded the latest Cuis image from http://www.jvuletich.org/Cuis/Index.html , and its amazingly fast.
¿Am I missing something?
Best 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
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now.
Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow... Michael
Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
easy for them. Damien could you start to make pharo-dev having less tools and that we see what is the default UI? David is working on a new version of the browser but in case of speed problem we should probably use the one of lukas. Stef
We really need to change this situation. As Lukas pointed out, its not the OmniBrowser implementation that is slow. There are some extended features of OmniBrowser that use computation intensive or inefficient parts of the system like PackageInfo. I really appreciate all these cool new features, but if they make the browser slow, they defeat the whole purpose. Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back. So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough. Cheers, Adrian On Jul 14, 2009, at 11:49 , Michael Rueger wrote:
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now.
Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard pravi:
We really need to change this situation.
As Lukas pointed out, its not the OmniBrowser implementation that is slow. There are some extended features of OmniBrowser that use computation intensive or inefficient parts of the system like PackageInfo. I really appreciate all these cool new features, but if they make the browser slow, they defeat the whole purpose.
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
I agree completely with Adrian here. Please switch off those dynamic category features and similar until they will run efficiently. Current impression speed-wise is actually very bad and only for the people with strong nerves. But for competition with other Smalltalks, no chance! And a chance with 1.0 release will be lost in a reputation you'll improve back very hard. JAnko
On Jul 14, 2009, at 11:49 , Michael Rueger wrote:
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now. Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
Michael
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
Yes david is working on that. I removed the package in senders and 'm working on a replacement for Package info (but not for tomorrow), Stef On Jul 14, 2009, at 12:30 PM, Adrian Lienhard wrote:
We really need to change this situation.
As Lukas pointed out, its not the OmniBrowser implementation that is slow. There are some extended features of OmniBrowser that use computation intensive or inefficient parts of the system like PackageInfo. I really appreciate all these cool new features, but if they make the browser slow, they defeat the whole purpose.
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
Cheers, Adrian
On Jul 14, 2009, at 11:49 , Michael Rueger wrote:
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now.
Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
Michael
_______________________________________________ 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
.
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
+9999999999999999999999999999 I recommend Pharo to a lot of people that was using Squeak and this is the first thing they told me and the first thing that happens. It doesn't matter how many fixes you did, or closures or traits. If you open a browser and takes 1 seconds. You close it. You even don't see all of the real features. And as Andrian says, they doesn't know why it is slow, or how to have a faster Pharo . They don't know what to remove or whateever. Please, we are loosing gays for this topic.
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
As I said, +999999999999999999999
Cheers, Adrian
On Jul 14, 2009, at 11:49 , Michael Rueger wrote:
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now.
Maybe we should point that out somewhere as we promote the dev-images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi all, 2009/7/14 Mariano Martinez Peck <marianopeck@gmail.com>:
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
+9999999999999999999999999999
+1 to that.
I recommend Pharo to a lot of people that was using Squeak and this is the first thing they told me and the first thing that happens. It doesn't matter how many fixes you did, or closures or traits. If you open a browser and takes 1 seconds. You close it. You even don't see all of the real features. And as Andrian says, they doesn't know why it is slow, or how to have a faster Pharo . They don't know what to remove or whateever.
Please, we are loosing gays for this topic.
An guys too ;-)
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
As I said, +999999999999999999999
+1 Regards, -- Esteban.
On Tue, Jul 14, 2009 at 12:05 PM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
Hi all,
2009/7/14 Mariano Martinez Peck <marianopeck@gmail.com>:
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
+9999999999999999999999999999
+1 to that.
I recommend Pharo to a lot of people that was using Squeak and this is the first thing they told me and the first thing that happens. It doesn't matter how many fixes you did, or closures or traits. If you open a browser and takes 1 seconds. You close it. You even don't see all of the real features. And as Andrian says, they doesn't know why it is slow, or how to have a faster Pharo . They don't know what to remove or whateever.
Please, we are loosing gays for this topic.
An guys too ;-)
hehehehe sorry. You understood me :)
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
As I said, +999999999999999999999
+1
Regards,
-- Esteban.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok we will fix that for 1.0 right now we are not even in beta. Stef
Users don't know the details and they don't care. If they open a Pharo image and its slow, then this just gives a bad impression. If people start telling each other "Pharo is slow", we will loose reputation that is very hard to win back.
+9999999999999999999999999999
I recommend Pharo to a lot of people that was using Squeak and this is the first thing they told me and the first thing that happens. It doesn't matter how many fixes you did, or closures or traits. If you open a browser and takes 1 seconds. You close it. You even don't see all of the real features. And as Andrian says, they doesn't know why it is slow, or how to have a faster Pharo . They don't know what to remove or whateever.
Please, we are loosing gays for this topic.
So I suggest to either disable the features that make the browser slow so that it is snappy again or to replace it with the version Lukas is using until it is fast enough.
As I said, +999999999999999999999
Cheers, Adrian
On Jul 14, 2009, at 11:49 , Michael Rueger wrote:
On Tue, Jul 14, 2009 at 11:47 AM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
take the core image. The default tools in web dev are too slow right now.
Maybe we should point that out somewhere as we promote the dev- images as being "Pharo"? As we can see from some of the discussion on the Squeak list people then think Pharo in general is dog slow...
Michael
_______________________________________________ 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
Can you elaborate on what is slow? Is this only Pharo or also Squeak? Adrian On Jul 17, 2009, at 01:07 , Douglas Brebner wrote:
Stéphane Ducasse wrote:
Ok we will fix that for 1.0 right now we are not even in beta.
As a minor point, running Pharo on a network drive is *horrifically* slow so don't do that :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard wrote:
Can you elaborate on what is slow? Is this only Pharo or also Squeak?
Anything that hits the changes file such as compiling or many MC operations. e.g. When you see the a popup saying "Snapshotting" it's time to go get something to eat. And yes, it affects Squeak too. The speed difference between running it on a local hard drive and a remote one is incredible.
Adrian
On Jul 17, 2009, at 01:07 , Douglas Brebner wrote:
Stéphane Ducasse wrote:
Ok we will fix that for 1.0 right now we are not even in beta.
As a minor point, running Pharo on a network drive is *horrifically* slow so don't do that :)
Douglas Brebner wrote:
Anything that hits the changes file such as compiling or many MC operations. e.g. When you see the a popup saying "Snapshotting" it's time to go get something to eat. And yes, it affects Squeak too.
Not only Squeak. Ever tried to open an OpenOffice document from a network drive? Michael
I imagine that the snapshotting goes over the SourceFiles I also know that nicolas proposed a speed up of latin files. Stef On Jul 17, 2009, at 11:22 AM, Douglas Brebner wrote:
Adrian Lienhard wrote:
Can you elaborate on what is slow? Is this only Pharo or also Squeak?
Anything that hits the changes file such as compiling or many MC operations. e.g. When you see the a popup saying "Snapshotting" it's time to go get something to eat. And yes, it affects Squeak too.
The speed difference between running it on a local hard drive and a remote one is incredible.
Adrian
On Jul 17, 2009, at 01:07 , Douglas Brebner wrote:
Stéphane Ducasse wrote:
Ok we will fix that for 1.0 right now we are not even in beta.
As a minor point, running Pharo on a network drive is *horrifically* slow so don't do that :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Speed is good, more speed is better. But my experience is that network drives are convenient (when they work), and otherwise slow and unreliable. Running a Smalltalk system over one is not something I would want to do for fear of losing the connection and therefore my work. Just my 2 asCents. Of course, it might be an interesting test case to profile to find a bottleneck. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Douglas Brebner Sent: Friday, July 17, 2009 4:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo-Dev/web Image slowness Adrian Lienhard wrote:
Can you elaborate on what is slow? Is this only Pharo or also Squeak?
Anything that hits the changes file such as compiling or many MC operations. e.g. When you see the a popup saying "Snapshotting" it's time to go get something to eat. And yes, it affects Squeak too. The speed difference between running it on a local hard drive and a remote one is incredible.
Adrian
On Jul 17, 2009, at 01:07 , Douglas Brebner wrote:
Stéphane Ducasse wrote:
Ok we will fix that for 1.0 right now we are not even in beta.
As a minor point, running Pharo on a network drive is *horrifically* slow so don't do that :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi estaban
I recently downloaded the latest Pharo Dev and Web images, and also the 2.8.4 one-click (which seems to be based on the Pharo image and VM too).
And I found out that its performance is terrible, it takes forever (you perceive the delay) to open a browser, browse senders, change a method selection on the OB or even do a "print-it" on a workspace.
However when accessing seaside through the web UI, it's blazing fast. Which makes me think there is something which is not working as it should.
PackageInfo and the package browser are slow. We are working on that. We removed recently the package annotation in the senders (because they scan all the image because of package info implementation) but we need this information to curve out etoys. You can take the default browser or the browser of lukas to get a much faster experience.
As a side note, I downloaded the latest Cuis image from http://www.jvuletich.org/Cuis/Index.html , and its amazingly fast.
As a side note. We do not consider ourselves in competition with Cuis. We integrated more than 1500 bug fixes and improvements (pragmas, closure compiler, traits....) and even more if we consider the version used in Cuis. We support truetype fonts and we are cleaning the system, when the cruft will be removed we will probably focus on making it faster. We are rewriting Package info from scratch. Now it takes time but feel free to join. Stef
Hi Stef, 2009/7/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi estaban [SNIP]
As a side note, I downloaded the latest Cuis image from http://www.jvuletich.org/Cuis/Index.html , and its amazingly fast.
As a side note. We do not consider ourselves in competition with Cuis. We integrated more than 1500 bug fixes and improvements (pragmas, closure compiler, traits....) and even more if we consider the version used in Cuis.
I know you're not competition, just put the example as a comparison of how fast a minimum image can run on actual hardware. I know Pharo is a superior alternative, with not only speed in mind. And I like its objective.
We support truetype fonts and we are cleaning the system, when the cruft will be removed we will probably focus on making it faster.
I understand, it just surprised me that an alpha release was such slow, as somebody said below its simple dissuasive to "give Pharo a try now it's alpha" and find that.
We are rewriting Package info from scratch. Now it takes time but feel free to join.
I hope to contribute with something, even if it's just a bug report/fix. Regards, -- Esteban.
Thanks esteban.
Hi Stef,
2009/7/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi estaban [SNIP]
As a side note, I downloaded the latest Cuis image from http://www.jvuletich.org/Cuis/Index.html , and its amazingly fast.
As a side note. We do not consider ourselves in competition with Cuis. We integrated more than 1500 bug fixes and improvements (pragmas, closure compiler, traits....) and even more if we consider the version used in Cuis.
I know you're not competition, just put the example as a comparison of how fast a minimum image can run on actual hardware.
I know Pharo is a superior alternative, with not only speed in mind. And I like its objective.
We support truetype fonts and we are cleaning the system, when the cruft will be removed we will probably focus on making it faster.
I understand, it just surprised me that an alpha release was such slow, as somebody said below its simple dissuasive to "give Pharo a try now it's alpha" and find that.
We are rewriting Package info from scratch. Now it takes time but feel free to join.
I hope to contribute with something, even if it's just a bug report/ fix.
Regards,
-- Esteban.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Hi estaban
I recently downloaded the latest Pharo Dev and Web images, and also the 2.8.4 one-click (which seems to be based on the Pharo image and VM too).
And I found out that its performance is terrible, it takes forever (you perceive the delay) to open a browser, browse senders, change a method selection on the OB or even do a "print-it" on a workspace.
However when accessing seaside through the web UI, it's blazing fast. Which makes me think there is something which is not working as it should.
PackageInfo and the package browser are slow. as I said Matthew already sped up PackageInfo by at least a factor of 10 in MC1.5
Keith
Dear Keith Can you please specify what's the proper way to update Monticello? Is there a way to do it without the Installer package? If the Installer package is really a must for updating Monticello, can you point what is the right way to install the Installer? Does the same procedure work equally for 3.9, 3.10 and Pharo images? Thanks in advance Hernán 2009/7/14 Keith Hodges <keith_hodges@yahoo.co.uk>
PackageInfo and the package browser are slow.
as I said Matthew already sped up PackageInfo by at least a factor of 10 in MC1.5
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I mean Monticello/PackageInfo Hernán 2009/7/14 Hernán Morales Durand <hernan.morales@gmail.com>
Dear Keith Can you please specify what's the proper way to update Monticello? Is there a way to do it without the Installer package? If the Installer package is really a must for updating Monticello, can you point what is the right way to install the Installer? Does the same procedure work equally for 3.9, 3.10 and Pharo images? Thanks in advance
Hernán
2009/7/14 Keith Hodges <keith_hodges@yahoo.co.uk>
PackageInfo and the package browser are slow.
as I said Matthew already sped up PackageInfo by at least a factor of 10 in MC1.5
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hernán Morales Durand wrote:
Dear Keith Can you please specify what's the proper way to update Monticello? Is there a way to do it without the Installer package? If the Installer package is really a must for updating Monticello, can you point what is the right way to install the Installer? Does the same procedure work equally for 3.9, 3.10 and Pharo images? Thanks in advance
Hernán See previous email.
Also Universes has an entry for Monticello1.5 and 1.6 Installer can load the source.st file from a mcz, this is needed to load Monticello. All the scripts for loading Monticello into various images are in InstallerScripts. Keith
So, please correct me if I am wrong: 1) The most secure cross-fork way to update Monticello for clean images is HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'. 2) Installer is necessary to update Monticello to 1.5 or 1.6 3) It is well-know that packages like OmniBrowser doesn't load after this update is done? (at least in Squeak images) See http://bugs.squeak.org/view.php?id=7369 Hernán 2009/7/14 Keith Hodges <keith_hodges@yahoo.co.uk>
Hernán Morales Durand wrote:
Dear Keith Can you please specify what's the proper way to update Monticello? Is there a way to do it without the Installer package? If the Installer package is really a must for updating Monticello, can you point what is the right way to install the Installer? Does the same procedure work equally for 3.9, 3.10 and Pharo images? Thanks in advance
Hernán See previous email.
Also Universes has an entry for Monticello1.5 and 1.6
Installer can load the source.st file from a mcz, this is needed to load Monticello. All the scripts for loading Monticello into various images are in InstallerScripts.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hernán Morales Durand wrote:
So, please correct me if I am wrong:
1) The most secure cross-fork way to update Monticello for clean images is
HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st <http://ftp.squeak.org/3.11/scripts/LPF.st>'. that method is not supported in older squeaks. 2) Installer is necessary to update Monticello to 1.5 or 1.6
3) It is well-know that packages like OmniBrowser doesn't load after this update is done? (at least in Squeak images)
Thats possibly a bug in OB, it calls withSubclassesDo: on a trait. Its not well known to me, fixing the above I can generate the dev images
See http://bugs.squeak.org/view.php?id=7369 If other patches are required, the monticello scripts for loading into Pharo are in InstallerScripts, and you are welcome to maintain them there
Keith
And I found out that its performance is terrible, it takes forever (you perceive the delay) to open a browser, browse senders, change a method selection on the OB or even do a "print-it" on a workspace.
I use images that have the same tools loaded as the Seaside One-Click image for all my development (see the load script <http://code.google.com/p/pharo/wiki/ImageBuildScripts>). I find it pretty snappy, however I use the standard Squeak look: UIThemeStandardSqueak beCurrent Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (11)
-
Adrian Lienhard -
Douglas Brebner -
Esteban A. Maringolo -
Hernán Morales Durand -
Janko Mivšek -
Keith Hodges -
Lukas Renggli -
Mariano Martinez Peck -
Michael Rueger -
Schwab,Wilhelm K -
Stéphane Ducasse