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: [email protected] > [[email protected] > ] On Behalf Of Alain Plantec [[email protected]] > Sent: Wednesday, July 15, 2009 6:19 PM > To: [email protected] > 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: [email protected] >>> [mailto:[email protected] >>> ] On Behalf Of Stéphane Ducasse >>> Sent: Wednesday, July 15, 2009 2:31 PM >>> To: [email protected] >>> 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: [email protected] >>>> [mailto:[email protected] >>>> ] On Behalf Of Stéphane Ducasse >>>> Sent: Wednesday, July 15, 2009 12:58 PM >>>> To: [email protected] >>>> 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 >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
