Before I started loading all the postcodes in the system, the image was about 80 MB. after loading all the postcodes it was about 108MB. Stuff I have loaded: Seaside (Complete) JQWidgetBox GemTools SqeaukSSL WebClient XMLSupport MockGemstone SqueakDBX MySQL CSV Query Extensions and my own projects. Looks like a typical image for me :) For the postcode lookup system, i have 397024 streets, (inst vars: city postcode name low high even latitude longitude), 9396 cities and 12 provinces. Not a complex model. They all are stored in IdentityBags. Indexes will be maintained by GemStone in the future, but for now I retrieve the address using: self streets select: [:each | each postcode = postcode ]. How do I get the output from the process browser in text? I only have about 13 processes where the input events fetching process takes about 30 procent and the rest is idle. Regards, Bart 2010/10/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Bart,
My image is 40 MB right now. Â That means you have about 100 MB of data? Â How do you store it? Â How many objects are there? Â Are they of fixed size? Â If so, you might try a quick experiment using a String or ByteArray wrapped with something that knows how to find a given code. Â You might be putting a pretty good load on the GC and using a blob to hold the data might help. Â I'm not sure where we are with respect to having a generational GC that would tenure and shrug off old objects.
IIRC, Alan Kay reported having a 160 MB Squeak image for demos, but that was many versions ago, so I hesitate to draw any comparisons. Â If you can find or get a copy of it, it might be interesting to open it in current VM to see how it performs.
Syntax highlighting is a possible offender, though I would not expect delays like you are describing. Â Do you by chance access the image over a remote desktop connection? Â Do you notice the problem with only certain methods?
What do you see in Tools|Process Browser? Â If you have a large number or processes running, it might explain a lot.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Saturday, October 16, 2010 8:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Speeding up Pharo 1.1
Bart,
On 16 Oct 2010, at 13:48, Bart Veenstra wrote:
Hi list,
I have been working with Pharo for almost a month now, and I suspect that the performance is degrading fast. UI tasks takes several seconds to react to my keyboard.
At work we use VAST and I have experience with VW as well and those smalltaks react to my keyboard and mouse actions instantly. But Pharo works very sluggish.
My image is about 130MB because I have loaded all dutch postcode in memory, but that should not affect the performance of general operations like typing with the keyboard. I am not a fast typer, but sometimes it takes seconds to show my keyboard input. I can't use the down key to select the right method from suggestions, because it seems to lockup completely.
Are there ways to speedup Pharo? I would love to use cogVM but I haven't got gemtools working on it...
Will upgrading to 1.1.1 fix these issues?
Is my OS (Windows 7-64bit) causing these issues?
Regards,
Bart
I am just guessing here, but I would suspect the slowdown to be related to completion/syntax coloring issues. You could try a pharo core image or one of lukas's builds (take development or seaside from http://hudson.lukas-renggli.ch/). In a large/old image, there could be lots of issues, of course.
HTH,
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project