- Pharo-dev - lists.pharo.org

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by StÃ©phane Ducasse

hi guys If you refer and change closed bug entry we will not see them. Since we look for fixed items. So please open new issues. Stef On Oct 16, 2010, at 10:27 PM, Pavel Krivanek wrote: > Can we add a setting for it? (issue > http://code.google.com/p/pharo/issues/detail?id=3113) > > Cheers, > -- Pavel > > On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> thanks! >> >> >> On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: >> >>> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. >>> >>> ISSUE 2653. >>> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… >>> >>> I did a test, maybe a good start would be to see if its failing now. >>> >>> Fernando >>> >>> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: >>> >>>> Hi Folks, >>>> >>>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> Mariano Martinez Peck wrote: >>>>> Guille, if I remember correctly (not sure), these new classes like >>>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>>>> think he is in the mailing list but not read it so frequently. So, for >>>>> this issues maybe you can cc'ed him. >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>>>> <mailto:guillermopolito@gmail.com>> >>>>> >>>>> Here is the piece of code that's behaving weird >>>>> >>>>> TextEditor>>dispatchOn: >>>>> >>>>> ... >>>>> ... >>>>> char := aKeyboardEvent keyCharacter. >>>>> openers := '([{'. >>>>> closers := ')]}'. >>>>> ( closers includes: char) ifTrue: [ self blinkPrevParen: >>>>> char ]. >>>>> result := self normalCharacter: aKeyboardEvent. >>>>> (self class autoEnclose and: [ openers includes: char ]) >>>>> not ifTrue: [ ^ result ]. >>>>> suffix := closers at: (openers indexOf: char). >>>>> paragraph text append: suffix asString. >>>>> self moveCursor: [ : position | position ] forward: true >>>>> specialBlock: [ : pos | "no special behavior" ] event: >>>>> aKeyboardEvent . >>>>> self userHasEdited. >>>>> >>>>> ------------------------------------- >>>>> >>>>> So, if I evaluate "TextEditor autoEnclose: false", it is stops >>>>> behaving like that :) >>>>> >>>>> What should be the desired behavior? Having it configurable as it >>>>> is today but fix the strange bracket adding? remove this behavior? >>>>> I can't find now how ParagraphEditor did this. >>>>> >>>>> Guille >>>>> >>>>> >>>>> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >>>>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>>> >>>>> Yes, the issue can be reduced to: >>>>> >>>>> open parenthesis (or brackets), then something else (anywhere >>>>> in the editor). >>>>> >>>>> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >>>>> <mailto:marianopeck@gmail.com>> >>>>> >>>>> I detected a similar problem: >>>>> >>>>> once you type an opening parenthesis, and then something >>>>> else, it adds a new one at the END of the code >>>>> >>>>> check http://code.google.com/p/pharo/issues/detail?id=2939 >>>>> >>>>> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >>>>> <mailto:guillermopolito@gmail.com>> >>>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=3069 >>>>> >>>>> if you type: >>>>> >>>>> [] -> []] >>>>> >>>>> () -> ()) >>>>> >>>>> {} -> {}} >>>>> >>>>> >>>>> >>>>> >>>>> Bye! >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Sat, 16 Oct 2010, 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. That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression: (WeakArray classPool at: #FinalizationDependents) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size ] There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing). If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive. Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. Levente > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Pavel Krivanek

Can we add a setting for it? (issue http://code.google.com/p/pharo/issues/detail?id=3113) Cheers, -- Pavel On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks! > > > On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > >> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. >> >> ISSUE 2653. >> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… >> >> I did a test, maybe a good start would be to see if its failing now. >> >> Fernando >> >> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: >> >>> Hi Folks, >>> >>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >>> >>> Cheers, >>> Juan Vuletich >>> >>> Mariano Martinez Peck wrote: >>>> Guille, if I remember correctly (not sure), these new classes like >>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>>> think he is in the mailing list but not read it so frequently. So, for >>>> this issues maybe you can cc'ed him. >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>>> <mailto:guillermopolito@gmail.com>> >>>> >>>> Â Â Here is the piece of code that's behaving weird >>>> >>>> Â Â TextEditor>>dispatchOn: >>>> >>>> Â Â ... >>>> Â Â ... >>>> Â Â char := aKeyboardEvent keyCharacter. >>>> Â Â Â Â openers := '([{'. >>>> Â Â Â Â closers := ')]}'. >>>> Â Â Â Â Â ( closers includes: char) ifTrue: [ self blinkPrevParen: >>>> Â Â char ]. >>>> Â Â Â Â Â result := self normalCharacter: aKeyboardEvent. >>>> Â Â Â Â Â (self class autoEnclose and: [ openers includes: char ]) >>>> Â Â not ifTrue: [ ^ result Â ]. >>>> Â Â Â Â suffix := closers at: (openers indexOf: char). >>>> Â Â Â Â paragraph text append: suffix asString. >>>> Â Â Â Â Â self moveCursor: [ : position | position Â ] forward: true >>>> Â Â specialBlock: [ : pos | "no special behavior" ] event: >>>> Â Â aKeyboardEvent . >>>> Â Â Â Â self userHasEdited. >>>> >>>> Â Â ------------------------------------- >>>> >>>> Â Â So, if I evaluate "TextEditor autoEnclose: false", it is stops >>>> Â Â behaving like that :) >>>> >>>> Â Â What should be the desired behavior? Â Having it configurable as it >>>> Â Â is today but fix the strange bracket adding? remove this behavior? >>>> Â Â I can't find now how ParagraphEditor did this. >>>> >>>> Â Â Guille >>>> >>>> >>>> Â Â On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >>>> Â Â <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> Â Â Â Â Yes, the issue can be reduced to: >>>> >>>> Â Â Â Â open parenthesis (or brackets), then something else (anywhere >>>> Â Â Â Â in the editor). >>>> >>>> Â Â Â Â 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >>>> Â Â Â Â <mailto:marianopeck@gmail.com>> >>>> >>>> Â Â Â Â Â Â I detected a similar problem: >>>> >>>> Â Â Â Â Â Â once you type an opening parenthesis, and then something >>>> Â Â Â Â Â Â else, it adds a new one at the END of the code >>>> >>>> Â Â Â Â Â Â check http://code.google.com/p/pharo/issues/detail?id=2939 >>>> >>>> Â Â Â Â Â Â 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >>>> Â Â Â Â Â Â <mailto:guillermopolito@gmail.com>> >>>> >>>> Â Â Â Â Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3069 >>>> >>>> Â Â Â Â Â Â Â Â if you type: >>>> >>>> Â Â Â Â Â Â Â Â [] -> []] >>>> >>>> Â Â Â Â Â Â Â Â () -> ()) >>>> >>>> Â Â Â Â Â Â Â Â {} -> {}} >>>> >>>> >>>> >>>> >>>> Â Â Â Â Â Â Â Â Bye! >>>> >>>> Â Â Â Â Â Â Â Â _______________________________________________ >>>> Â Â Â Â Â Â Â Â Pharo-project mailing list >>>> Â Â Â Â Â Â Â Â Pharo-project(a)lists.gforge.inria.fr >>>> Â Â Â Â Â Â Â Â <mailto:Pharo-project@lists.gforge.inria.fr> >>>> Â Â Â Â Â Â Â Â http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> Â Â Â Â Â Â _______________________________________________ >>>> Â Â Â Â Â Â Pharo-project mailing list >>>> Â Â Â Â Â Â Pharo-project(a)lists.gforge.inria.fr >>>> Â Â Â Â Â Â <mailto:Pharo-project@lists.gforge.inria.fr> >>>> Â Â Â Â Â Â http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> >>>> Â Â _______________________________________________ >>>> Â Â Pharo-project mailing list >>>> Â Â Pharo-project(a)lists.gforge.inria.fr >>>> Â Â <mailto:Pharo-project@lists.gforge.inria.fr> >>>> Â Â http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

While doing the SpaceTally new printSpaceAnalysis my image is locking up. Looked like it would take some time, so started playing Medal of Honor (recommend it!!) Anyhow.. Back in Pharo I have a WARNING, Event buffer overflow in the bottom...anyway to repair this without closing the image? 2010/10/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Just by cursious, could you do a SpaceTally new printSpaceAnalysis > and attach the generated file STspace.text > > In addition, you could do some cleaning, at least to decrease the size of > the image. > You can try to do "ScriptLoader new cleanUpForRelease" > > Let us know > > Mariano > > On Sat, Oct 16, 2010 at 7:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Something produces too much garbage. >> It could be anything. >> But most of the times, the cause of sluggines is finalization process. >> >> On 16 October 2010 16:37, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > I can feel this slugginess too, and we should fix that for good. >> > >> > A clue: in Squeak trunk, here are the VM stats: >> > uptime Â Â Â Â Â Â Â Â Â 0h7m59s >> > memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >> > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >> > Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >> > Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >> > Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >> > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >> > Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >> > Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >> > Since last view -7,895 >> > Â Â Â Â uptime Â Â Â Â Â 71.2s >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), >> > avg 105.0ms >> > Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >> > Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >> > >> > In Pharo: >> > uptime Â Â Â Â Â Â Â Â Â 0h6m48s >> > memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >> > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >> > Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >> > Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >> > Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >> > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >> > 278.0ms >> > Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >> > Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >> > Since last view 4,777 (85ms between GCs) >> > Â Â Â Â uptime Â Â Â Â Â 404.5s >> > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >> > -285.0ms >> > Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >> > Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >> > >> > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >> > Could it be object creation at each event or something like that? >> > >> > Nicolas >> > >> > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> 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(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

2010/10/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/10/16 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Bart, Nicolas, >> Â Â Â Bart, are you using the standard VM or Cog? >> Â Â Â Nicolas, if this is the standard VM then do the two images have the same >> value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? Â If not, that >> could account for the difference in incremental GC frequency (in Cog the IGC >> trigger mechanism is different, based on space allocated not allocation >> count). >> >> HTH >> Eliot > > Oh, comparison was not fair, I ran Squeak with COG. > When I try COG+Pharo, some updates are missing, I can't print the VMstats. > > Nicolas > Well, I mean in #spyAllEvery:on: Nicolas >> On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> I can feel this slugginess too, and we should fix that for good. >>> >>> A clue: in Squeak trunk, here are the VM stats: >>> uptime Â Â Â Â Â Â Â Â Â 0h7m59s >>> memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >>> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >>> Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >>> Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >>> Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >>> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >>> Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >>> Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >>> Since last view -7,895 >>> Â Â Â Â uptime Â Â Â Â Â 71.2s >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg >>> 105.0ms >>> Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >>> Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >>> >>> In Pharo: >>> uptime Â Â Â Â Â Â Â Â Â 0h6m48s >>> memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >>> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >>> Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >>> Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >>> Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >>> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >>> 278.0ms >>> Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >>> Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >>> Since last view 4,777 (85ms between GCs) >>> Â Â Â Â uptime Â Â Â Â Â 404.5s >>> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >>> -285.0ms >>> Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >>> Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >>> >>> A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >>> Could it be object creation at each event or something like that? >>> >>> Nicolas >>> >>> 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >>> > 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(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

2010/10/16 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Bart, Nicolas, > Â Â Â Bart, are you using the standard VM or Cog? > Â Â Â Nicolas, if this is the standard VM then do the two images have the same > value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? Â If not, that > could account for the difference in incremental GC frequency (in Cog the IGC > trigger mechanism is different, based on space allocated not allocation > count). > > HTH > Eliot Oh, comparison was not fair, I ran Squeak with COG. When I try COG+Pharo, some updates are missing, I can't print the VMstats. Nicolas > On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> I can feel this slugginess too, and we should fix that for good. >> >> A clue: in Squeak trunk, here are the VM stats: >> uptime Â Â Â Â Â Â Â Â Â 0h7m59s >> memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes >> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) >> Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) >> Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) >> Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) >> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >> Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms >> Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) >> Since last view -7,895 >> Â Â Â Â uptime Â Â Â Â Â 71.2s >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg >> 105.0ms >> Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg >> Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) >> >> In Pharo: >> uptime Â Â Â Â Â Â Â Â Â 0h6m48s >> memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes >> Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) >> Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) >> Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) >> Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) >> GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg >> 278.0ms >> Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms >> Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) >> Since last view 4,777 (85ms between GCs) >> Â Â Â Â uptime Â Â Â Â Â 404.5s >> Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg >> -285.0ms >> Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms >> Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) >> >> A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. >> Could it be object creation at each event or something like that? >> >> Nicolas >> >> 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> > 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(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Eliot Miranda

Hi Bart, Nicolas, Bart, are you using the standard VM or Cog? Nicolas, if this is the standard VM then do the two images have the same value for allocationsBetweenGCs (Smalltalk vmParameterAt: 5)? If not, that could account for the difference in incremental GC frequency (in Cog the IGC trigger mechanism is different, based on space allocated not allocation count). HTH Eliot On Sat, Oct 16, 2010 at 6:37 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > I can feel this slugginess too, and we should fix that for good. > > A clue: in Squeak trunk, here are the VM stats: > uptime 0h7m59s > memory 59,647,648 bytes > old 48,744,032 bytes (81.7%) > young 545,352 bytes (0.9%) > used 49,289,384 bytes (82.6%) > free 10,358,264 bytes (17.4%) > GCs 288 (1665ms between GCs) > full 0 totalling 0ms (0.0% uptime) > incr 288 totalling 486ms (0.0% uptime), avg 2.0ms > tenures 15 (avg 19 GCs/tenure) > Since last view -7,895 > uptime 71.2s > full -15 totalling -1,576ms (-2.0% uptime), avg > 105.0ms > incr -7880 totalling -1,952ms (-3.0% uptime), avg > tenures -548 (avg 14 GCs/tenure) > > In Pharo: > uptime 0h6m48s > memory 29,690,612 bytes > old 25,210,060 bytes (84.9%) > young 252,096 bytes (0.8%) > used 25,462,156 bytes (85.80000000000001%) > free 4,228,456 bytes (14.200000000000001%) > GCs 4,969 (82ms between GCs) > full 3 totalling 834ms (0.2% uptime), avg 278.0ms > incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > tenures 75 (avg 66 GCs/tenure) > Since last view 4,777 (85ms between GCs) > uptime 404.5s > full 1 totalling -285ms (-0.1% uptime), avg > -285.0ms > incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > tenures 75 (avg 63 GCs/tenure) > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > Could it be object creation at each event or something like that? > > Nicolas > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > > 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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Mariano Martinez Peck

Just by cursious, could you do a SpaceTally new printSpaceAnalysis and attach the generated file STspace.text In addition, you could do some cleaning, at least to decrease the size of the image. You can try to do "ScriptLoader new cleanUpForRelease" Let us know Mariano On Sat, Oct 16, 2010 at 7:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Something produces too much garbage. > It could be anything. > But most of the times, the cause of sluggines is finalization process. > > On 16 October 2010 16:37, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I can feel this slugginess too, and we should fix that for good. > > > > A clue: in Squeak trunk, here are the VM stats: > > uptime 0h7m59s > > memory 59,647,648 bytes > > old 48,744,032 bytes (81.7%) > > young 545,352 bytes (0.9%) > > used 49,289,384 bytes (82.6%) > > free 10,358,264 bytes (17.4%) > > GCs 288 (1665ms between GCs) > > full 0 totalling 0ms (0.0% uptime) > > incr 288 totalling 486ms (0.0% uptime), avg 2.0ms > > tenures 15 (avg 19 GCs/tenure) > > Since last view -7,895 > > uptime 71.2s > > full -15 totalling -1,576ms (-2.0% uptime), avg > 105.0ms > > incr -7880 totalling -1,952ms (-3.0% uptime), avg > > tenures -548 (avg 14 GCs/tenure) > > > > In Pharo: > > uptime 0h6m48s > > memory 29,690,612 bytes > > old 25,210,060 bytes (84.9%) > > young 252,096 bytes (0.8%) > > used 25,462,156 bytes (85.80000000000001%) > > free 4,228,456 bytes (14.200000000000001%) > > GCs 4,969 (82ms between GCs) > > full 3 totalling 834ms (0.2% uptime), avg > 278.0ms > > incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > > tenures 75 (avg 66 GCs/tenure) > > Since last view 4,777 (85ms between GCs) > > uptime 404.5s > > full 1 totalling -285ms (-0.1% uptime), avg > -285.0ms > > incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > > tenures 75 (avg 63 GCs/tenure) > > > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > > Could it be object creation at each event or something like that? > > > > Nicolas > > > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > >> 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(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

Something produces too much garbage. It could be anything. But most of the times, the cause of sluggines is finalization process. On 16 October 2010 16:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I can feel this slugginess too, and we should fix that for good. > > A clue: in Squeak trunk, here are the VM stats: > uptime Â Â Â Â Â Â Â Â Â 0h7m59s > memory Â Â Â Â Â Â Â Â Â 59,647,648 bytes > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 48,744,032 bytes (81.7%) > Â Â Â Â young Â Â Â Â Â 545,352 bytes (0.9%) > Â Â Â Â used Â Â Â Â Â Â 49,289,384 bytes (82.6%) > Â Â Â Â free Â Â Â Â Â Â 10,358,264 bytes (17.4%) > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 288 (1665ms between GCs) > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) > Â Â Â Â incr Â Â Â Â Â Â 288 totalling 486ms (0.0% uptime), avg 2.0ms > Â Â Â Â tenures Â Â Â Â 15 (avg 19 GCs/tenure) > Since last view -7,895 > Â Â Â Â uptime Â Â Â Â Â 71.2s > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms > Â Â Â Â incr Â Â Â Â Â Â -7880 totalling -1,952ms (-3.0% uptime), avg > Â Â Â Â tenures Â Â Â Â -548 (avg 14 GCs/tenure) > > In Pharo: > uptime Â Â Â Â Â Â Â Â Â 0h6m48s > memory Â Â Â Â Â Â Â Â Â 29,690,612 bytes > Â Â Â Â old Â Â Â Â Â Â Â Â Â Â 25,210,060 bytes (84.9%) > Â Â Â Â young Â Â Â Â Â 252,096 bytes (0.8%) > Â Â Â Â used Â Â Â Â Â Â 25,462,156 bytes (85.80000000000001%) > Â Â Â Â free Â Â Â Â Â Â 4,228,456 bytes (14.200000000000001%) > GCs Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4,969 (82ms between GCs) > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 3 totalling 834ms (0.2% uptime), avg 278.0ms > Â Â Â Â incr Â Â Â Â Â Â 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms > Â Â Â Â tenures Â Â Â Â 75 (avg 66 GCs/tenure) > Since last view 4,777 (85ms between GCs) > Â Â Â Â uptime Â Â Â Â Â 404.5s > Â Â Â Â full Â Â Â Â Â Â Â Â Â Â 1 totalling -285ms (-0.1% uptime), avg -285.0ms > Â Â Â Â incr Â Â Â Â Â Â 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms > Â Â Â Â tenures Â Â Â Â 75 (avg 63 GCs/tenure) > > A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. > Could it be object creation at each event or something like that? > > Nicolas > > 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: >> 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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Schwab,Wilhelm K

Are those negative numbers in the Squeak stats? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Saturday, October 16, 2010 9:37 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Speeding up Pharo 1.1 I can feel this slugginess too, and we should fix that for good. A clue: in Squeak trunk, here are the VM stats: uptime 0h7m59s memory 59,647,648 bytes old 48,744,032 bytes (81.7%) young 545,352 bytes (0.9%) used 49,289,384 bytes (82.6%) free 10,358,264 bytes (17.4%) GCs 288 (1665ms between GCs) full 0 totalling 0ms (0.0% uptime) incr 288 totalling 486ms (0.0% uptime), avg 2.0ms tenures 15 (avg 19 GCs/tenure) Since last view -7,895 uptime 71.2s full -15 totalling -1,576ms (-2.0% uptime), avg 105.0ms incr -7880 totalling -1,952ms (-3.0% uptime), avg tenures -548 (avg 14 GCs/tenure) In Pharo: uptime 0h6m48s memory 29,690,612 bytes old 25,210,060 bytes (84.9%) young 252,096 bytes (0.8%) used 25,462,156 bytes (85.80000000000001%) free 4,228,456 bytes (14.200000000000001%) GCs 4,969 (82ms between GCs) full 3 totalling 834ms (0.2% uptime), avg 278.0ms incr 4966 totalling 6,280ms (1.5% uptime), avg 1.3ms tenures 75 (avg 66 GCs/tenure) Since last view 4,777 (85ms between GCs) uptime 404.5s full 1 totalling -285ms (-0.1% uptime), avg -285.0ms incr 4776 totalling 6,088ms (1.5% uptime), avg 1.3ms tenures 75 (avg 63 GCs/tenure) A GC every 82ms, 20x+ more GC than trunk... Something is going wrong. Could it be object creation at each event or something like that? Nicolas 2010/10/16 Sven Van Caekenberghe <sven(a)beta9.be>: > 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 16, 2010