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

Re: [Pharo-project] Speeding up Pharo 1.1

by Bart Veenstra

After MCMethodDefinition shutDown it looks like it is reacting a bit faster to keyboard input. I often experience sluggishness in autocompletion method. When I type in a name of a class in a workspace, the autocomplete suggests 3 options. I want to choose the middle, so I press down and after 3 seconds (or sometimes nothging happens) it selects the class. The longer I have my image open, the longer this will take :S 2010/10/17 Igor Stasenko <siguctua(a)gmail.com>: > Bart, > can you try doing: > > MCMethodDefinition shutDown > > in your image? > > On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> 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 >> >> _______________________________________________ >> 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. 18, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by StÃ©phane Ducasse

> > This benchmark is the real concurrent stress test. 100 processes are adding 10,000 elements to the queue while another 100 are reading from it. It clearly shows that Igor's queues are an order of magnitude faster. Also 200 concurrent processes cause much less slowdown compared to the sequential tests for them. > > So, even though SharedQueue is now faster than SharedQueue2, both will have to go IMHO. :) Hi Levente Naively why? and replace by what? Stef

Oct. 18, 2010

[Pharo-project] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by Levente Uzonyi

On Sun, 17 Oct 2010, Levente Uzonyi wrote: snip > SharedQueue's code for "growing" (#makeRoomAtEnd) is crap IMHO. Because of > that it takes O(n) time to add or remove and element to or from the queue. > SharedQueue2 is a lot better approach, because it doesn't try to > reimplement a dynamic array, but uses OrderedCollection instead. I uploaded a new version of that method to the Trunk. I don't think it's really useful, because I'm pretty sure we will get rid of both SharedQueue and SharedQueue2 in the near future. Anyway I did some benchmarks using Cog, and SharedQueue became surprisingly good, though it's still not even close to Igor's new FIFOQueue or AtomicSharedQueue. Benchmark #1: Make a large queue { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ :queueClass | | queue | queue := queueClass new. queueClass -> ( (1 to: 5) collect: [ :run | Smalltalk garbageCollect. { [ 1 to: 1000000 do: [ :each | queue nextPut: each ] ] timeToRun. [ 1 to: 1000000 do: [ :each | queue next ] ] timeToRun } ]) ]. SharedQueue->#(#(1028 1615) #(945 1557) #(976 2322) #(492 459) #(489 476)). SharedQueue2->#(#(1976 2284) #(1318 8298) #(982 692) #(1005 675) #(1002 665)). FIFOQueue->#(#(180 67) #(184 67) #(182 69) #(181 66) #(177 67)). AtomicSharedQueue->#(#(208 66) #(207 67) #(209 66) #(213 68) #(209 65)). This benchmark is similar to what Igor used, but it doesn't create a new queue between runs. It simply adds 1,000,000 elements then removes them which is a pretty unrealistic scenario for a shared queue. The effect of GC is pretty high on this benchmark, probably that's responsible for the high spikes. Benchmark #2: Sequential throughput test { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ :queueClass | | queue | queue := queueClass new. queueClass -> ( (1 to: 5) collect: [ :run | | results | Smalltalk garbageCollect. results := #(0 0). 1 to: 1000 do: [ :round | results := results + { [ 1 to: 1000 do: [ :each | queue nextPut: each ] ] timeToRun. [ 1 to: 1000 do: [ :each | queue next ] ] timeToRun } ]. results ]) ]. SharedQueue->#(#(464 452) #(472 436) #(466 437) #(463 449) #(462 452)). SharedQueue2->#(#(949 692) #(980 663) #(984 670) #(992 670) #(958 677)). FIFOQueue->#(#(125 67) #(263 62) #(250 76) #(262 63) #(247 81)). AtomicSharedQueue->#(#(154 70) #(264 77) #(273 62) #(275 63) #(265 71)). This is similar to benchmark #1, but instead of adding and removing 1,000,000 at once it's chunked up to 1,000 equal parts. It's more realistic than benchmark #1. It's interesting that both FIFOQueue and AtomicSharedQueue performed better in the previous benchmark, unlike the other two queues, which are better here. Benchmark #3: Concurrent throughput test { SharedQueue. SharedQueue2. FIFOQueue. AtomicSharedQueue } collect: [ :queueClass | | queue semaphore | queue := queueClass new. semaphore := Semaphore new. queueClass -> ( (1 to: 5) collect: [ :run | | producers consumers | Smalltalk garbageCollect. producers := (1 to: 100) collect: [ :each | [ 1 to: 10000 do: [ :index | queue nextPut: each ] ] newProcess ]. consumers := (1 to: 100) collect: [ :each | [ 1 to: 10000 do: [ :index | queue next ]. semaphore signal ] newProcess ]. [ consumers do: [ :each | each priority: 39; resume ]. producers do: [ :each | each priority: 39; resume ]. 100 timesRepeat: [ semaphore wait ] ] timeToRun ]) ]. SharedQueue->#(3143 2977 3034 2949 3021). SharedQueue2->#(4280 4384 4179 4160 4181). FIFOQueue->#(245 311 252 254 255). AtomicSharedQueue->#(277 274 277 280 274) This benchmark is the real concurrent stress test. 100 processes are adding 10,000 elements to the queue while another 100 are reading from it. It clearly shows that Igor's queues are an order of magnitude faster. Also 200 concurrent processes cause much less slowdown compared to the sequential tests for them. So, even though SharedQueue is now faster than SharedQueue2, both will have to go IMHO. :) Levente snip

Oct. 18, 2010

Re: [Pharo-project] A Lazy Inspector?

by Felipe Ignacio Valverde Campos

I don't know the first question's answer, but, you can stop an execution code using Alt+. (or similar key + .) -- Estudiante de IngenierÃa Civil en ComputaciÃ³n Departamento de Ciencias de la ComputaciÃ³n Universidad de Chile http://www.dcc.uchile.cl/~fvalverd/public_key.asc

Oct. 18, 2010

[Pharo-project] A Lazy Inspector?

by Oscar E A Callau

Hello all, I was wondering what actually the inspector does in the following case: When you explore (or inspect) the expression: Class environment you get all classes in the system dictionary. If you navigate inside a class, for example AColorSelectorMorph, you can see all its properties and one of them is environment, if you go inside it, you get again all classes in the system dictionary. So, you can repeat this infinitely (or until you get run out of memory, I guess) Is it the behavior of a lazy inspector? If true, why I cannot inspect a mutually-recursive class definition, like this: Object subclass: #Foo instanceVariableNames: 'bar' classVariableNames: '' poolDictionaries: '' category: '' Foo>>initialize bar:= Bar new Object subclass: #Bar instanceVariableNames: 'foo' classVariableNames: '' poolDictionaries: '' category: '' Foo>>initialize bar:= Foo new Thanks in advance. P.S.: How can I stop my execution in the pharo image when it is in a infinite loop? I can't remember what the shortcut was.

Oct. 18, 2010

Re: [Pharo-project] SharedQueue doesn't scale

by Levente Uzonyi

On Sat, 16 Oct 2010, Igor Stasenko wrote: > 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. SharedQueue's code for "growing" (#makeRoomAtEnd) is crap IMHO. Because of that it takes O(n) time to add or remove and element to or from the queue. SharedQueue2 is a lot better approach, because it doesn't try to reimplement a dynamic array, but uses OrderedCollection instead. Btw calling a LIFO datastructure a queue is strange, because a queue is always FIFO. Please call it a stack. Levente > > 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. > > _______________________________________________ > 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 Sun, 17 Oct 2010, Henrik Sperre Johansen wrote: > > > Levente Uzonyi-2 wrote: >> >> >> Btw why doesn't the windows VM signal the semaphore? >> >> >> Levente >> >> >> > > http://forum.world.st/InputSemaphore-on-Windows-td1934394.html#a2014576 > > Basically, there may or may not be some issue with them not being noticed in > the image, it hasn't been a priority since the Squeak image doesn't depend > on it, and no-one have set aside the time to fix it. > Not very hard really, just time-consuming and tedious checking you've hit > all the points it has to be signalled. So someone has to do it and it will work. :) Waiting for the signal with a timeout can also tell if there's code in the vm that doesn't signal the semaphore. If the waiting ends because of the timeout, but there are new events available, then we can be pretty sure there's more VM code to be fixed. Levente > > Cheers, > Henry > -- > View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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 Igor Stasenko

Bart, can you try doing: MCMethodDefinition shutDown in your image? On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> 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 > > _______________________________________________ > 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. 17, 2010

[Pharo-project] [update 1.2] #12195

by StÃ©phane Ducasse

12195 ----- - Issue 3113: TextEditor autoEnclose settings. Thanks Pavel Krivanek. - Issue 3110: ProjectLauncher readDocumentAtStartup needs a setting. Thanks Pavel Krivanek. - Issue 3103: better Morphic detection in AutoStart startUp:. Thanks Pavel Krivanek. - Issue 3102: removeAllButPackages: hackish method. Thanks Pavel Krivanek.

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 17.10.2010 20:49, Igor Stasenko wrote: > On 17 October 2010 21:45, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> Levente Uzonyi-2 wrote: >>> >>> Btw why doesn't the windows VM signal the semaphore? >>> >>> >>> Levente >>> >>> >>> >> http://forum.world.st/InputSemaphore-on-Windows-td1934394.html#a2014576 >> >> Basically, there may or may not be some issue with them not being noticed in >> the image, it hasn't been a priority since the Squeak image doesn't depend >> on it, and no-one have set aside the time to fix it. >> Not very hard really, just time-consuming and tedious checking you've hit >> all the points it has to be signalled. >> > I don't think that this is the problem with image being sluggy. > It would feel sluggy from very beginning, not after you load a lots of > stuff into image, isnt? > Yup, this was mainly to answer why Pharo doesn't use the InputSemaphore, a short detour which hopefully ends here. I don't have an image which has been running for 7 hours (non-core at least), and haven't experienced the slowdown reported myself, so didn't feel qualified to comment on that matter. Cheers, Henry

Oct. 17, 2010