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