October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

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 >

Oct. 16, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Sven Van Caekenberghe

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

Oct. 16, 2010

[Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

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

Oct. 16, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

2010/10/15 <mkobetic(a)gmail.com>: > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> I've tested this strategy, and it works well: >> >> - use accessors self input/self output instead of inst. var. >> - lazily initialize the input for Collection and File > > Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > The tests interleaving read/write are #testWriteFromCollectionAt #testWriteFromStream #testWriteTransformHexToByte #testReadWriteLargeAmount Then #testGetPastEnd also relies on become: on close... If we change the grown policy: destination := destination grownBy: (destination size max: 10) instead of: destination := destination grownBy: (destination size max: 1) then the test does not pass. This also is because I used: input := outer terminal reading rather than: input := outer conclusion reading >> In collection tests, I have used >> Â Â Â ^input ifNil:[input := outer terminal reading] >> where: outer := output := collection writing. >> This is because some Block transforms can't access the terminal collection... > > Not sure what you mean, but it will probably get clearer when I go do it. > BlockWriteStream terminal answers a block... But yes, it will be clearer when debugging it. > BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. > > Martin > Nice. Squeak lack package comment.... :( Nicolas

Oct. 16, 2010

[Pharo-project] [ANN] Atomic collections.

by Igor Stasenko

Hello, as a result of recently happened discussion about atomic operations, i implemented two kinds of thread-safe queues FIFO and LIFO, which using atomic operations, instead of semaphore to add/remove items. You may review it by loading the code from SqueakSource: MCHttpRepository location: 'http://www.squeaksource.com/Atomics' user: '' password: '' FIFOQueue scales much better than SharedQueue, and after some additional testing can fully replace it. I tested FIFOQueue by replacing a SharedQueue class for EventSensor (a core system part, responsible for delivering events). In attached file you can find a patch, which will make your sensor to work with FIFOQueue, after you save image, or do 'EventSensor install'. There are also a heavy-concurrency tests in corresponding test classes, which is passing ok. Concurrency is highly complex field, thus i won't be surprised if code still contains a bugs. Code license is MIT, moreover a repository is publicly writeable, so if you wanna add tests, benchmarks, fixes, or implement new kind of lock-free container, feel free to do it. Any feedback is welcome. -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] Example of non-concurrent code :)

by John M McIntosh

Igor, take a look back in the messages from January 25th 2010 Re: [Pharo-project] new mac menu code There may be something related there? On 2010-10-15, at 9:41 PM, Igor Stasenko wrote: > mouseTrailFrom: currentBuf > "Current event, a mouse event buffer, is about to be processed. If > there are other similar mouse events queued up, then drop them from > the queue, and report the positions inbetween." > > | nextEvent trail | > trail := (Array new: 1) writeStream. > trail nextPut: currentBuf third @ currentBuf fourth. > *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: > [nextEvent first = currentBuf first > ifFalse: [^trail contents "different event type"]. > nextEvent fifth = currentBuf fifth > ifFalse: [^trail contents "buttons changed"]. > nextEvent sixth = currentBuf sixth > ifFalse: [^trail contents "modifiers changed"]. > "nextEvent is similar. Remove it from the queue, and check the next." > *b* nextEvent := Sensor nextEvent. > trail nextPut: nextEvent third @ nextEvent fourth]. > ^trail contents > > > Here, the bug: > first it sends #peekEvent and its not nil. > Okay, then after some logic voodo, it sends nextEvent, without > precaution, that it may also answer nil! > > So, if some other process get between these two sends (*a*, *b*) and > fetch/flush all events, a code will fail, > because > 'nextEvent third' is DNU , when nextEvent == nil. > > The fix is simple: > > nextEvent := Sensor nextEvent. > nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] > > Both Pharo & Squeak contain this bug. But this method slightly differs > from each other. > > -- > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 16, 2010

[Pharo-project] Example of non-concurrent code :)

by Igor Stasenko

mouseTrailFrom: currentBuf "Current event, a mouse event buffer, is about to be processed. If there are other similar mouse events queued up, then drop them from the queue, and report the positions inbetween." | nextEvent trail | trail := (Array new: 1) writeStream. trail nextPut: currentBuf third @ currentBuf fourth. *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: [nextEvent first = currentBuf first ifFalse: [^trail contents "different event type"]. nextEvent fifth = currentBuf fifth ifFalse: [^trail contents "buttons changed"]. nextEvent sixth = currentBuf sixth ifFalse: [^trail contents "modifiers changed"]. "nextEvent is similar. Remove it from the queue, and check the next." *b* nextEvent := Sensor nextEvent. trail nextPut: nextEvent third @ nextEvent fourth]. ^trail contents Here, the bug: first it sends #peekEvent and its not nil. Okay, then after some logic voodo, it sends nextEvent, without precaution, that it may also answer nil! So, if some other process get between these two sends (*a*, *b*) and fetch/flush all events, a code will fail, because 'nextEvent third' is DNU , when nextEvent == nil. The fix is simple: nextEvent := Sensor nextEvent. nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] Both Pharo & Squeak contain this bug. But this method slightly differs from each other. -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

[Pharo-project] SharedQueue doesn't scale

by Igor Stasenko

Hello, just out of interest, i tried to compare the speed of my FIFOQueue implementation and SharedQueue, using Levente's benchmarks for stack: "The linked Stack implementation" (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := FIFOQueue new. { [ 1 to: 1000000 do: [ :each | stack nextPut: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack next ] ] timeToRun } ] #(#(291 69) #(170 65) #(168 66) #(168 65) #(168 65)) Then i changed FIFOQueue to SharedQueue and run it again.. waiting 1 minute.. wait a bit more.. then i came to smoke.. and after returning, it was still running.. i interrupted it, and inspected the queue size.. it was slightly above 300000 items. Of course, SharedQueue usually not used in scenarios, where you need to push such large number of items. So, its just a warning. Btw, here is another comparison (Stack vs thread-safe LIFO queue): (1 to: 5) collect: [ :run | | stack | Smalltalk garbageCollect. stack := Stack new. { [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] Stack: #(#(166 94) #(160 90) #(162 91) #(162 92) #(160 92)) LIFOQueue: #(#(172 250) #(174 248) #(172 250) #(174 252) #(172 250)) Yes, it is slower (mainly for reading). But it is price for being thread safe :) -- Best regards, Igor Stasenko AKA sig.

Oct. 16, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

I don't like it either, but sometimes you have to use it... 2010/10/15 laurent laffont <laurent.laffont(a)gmail.com> > PerformedExperiment class >> >> for: anExperiment >> startedAt: aStartTime >> stopedAt: aStopTime >> madeBy: aParticipant >> with: aCollectionOfTasks. >> | instance | >> instance := self new. >> instance >> initializeFor: anExperiment >> startedAt: aStartTime >> stopedAt: aStopTime >> madeBy: aParticipant >> with: aCollectionOfTasks. >> ^ instance >> > > > I don't really like this way of formatting the message with line breaks. I > agree on Inline Message Pattern in Kent Beck's Smalltalk Best Practice > Patterns. There's the draft here > > http://stephane.ducasse.free.fr/FreeBooks/BestSmalltalkPractices/Draft-Smal… > > Look at p.127 / 128 > > > Cheers, > > Laurent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

thanks levente! this is always nice to read such kind of post since they educate us and we need that :) I want to be taught a lot :) Stef On Oct 15, 2010, at 6:33 PM, Levente Uzonyi wrote: > On Thu, 14 Oct 2010, jaayer wrote: > >> There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. >> >> Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: >> >> Pushing is roughly ~30% faster: >> r1 :=[100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]]] timeToRun. >> r2 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]]] timeToRun. >> 100 - ((r1 / r2) asFloat * 100). >> >> as is pushing + popping: >> r3 := [100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]. >> 10 timesRepeat: [s pop]]] timeToRun. >> r4 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]. >> 10 timesRepeat: [oc removeLast]]] timeToRun. >> 100 - ((r3 / r4) asFloat * 100). > > Please write more realistic benchmarks. Adding 10 elements to your Stack implementation won't make it's array grow. Also the benchmark measures a lot of other stuff besides the cost of push and pop. Something like this should do it: > > "The linked Stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(167 88) #(169 91) #(169 88) #(166 87) #(166 88)) > > "OrderedCollection" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := OrderedCollection new. > { > [ 1 to: 1000000 do: [ :each | stack addLast: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack removeLast ] ] timeToRun } ] > #(#(87 98) #(87 100) #(87 98) #(88 97) #(87 99)) > > "The new stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(89 62) #(90 63) #(89 62) #(89 62) #(89 64)) > > All benchmarks were run in the latest Squeak 4.2 alpha using the latest CogVM. > > Conclusion: OrderedCollection >> #removeLast uses #emptyCheck which is slow. Other than that the difference between OrderedCollection and an array-based stack implementation is neglible in Squeak using CogVM. > > Replacing > self emptyCheck > with > lastIndex < firstIndex ifTrue: [ self errorEmptyCollection] > in OrderedCollection >> #removeLast and running the benchmark again gives the following results: > #(#(88 65) #(90 66) #(89 66) #(88 68) #(87 66)) > > > Also please send #postCopy to super if you implement #postCopy. > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010