November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

by Nicolai Hess

That is better, 5 minutes instead of 15 ! 2015-11-22 12:16 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > If you only need it for yourself you could probably speed things up by > doing > > Smalltalk closeSourceFiles. [ compileâ¦ ] ensure: [ Smalltalk > openSourceFiles ]. > > That will prevent reads and writes from and to the changes / sources > files. Of course, that doesnât solve the problem in general. > > Cheers, > Max > > > > On 21 Nov 2015, at 20:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > recompiling all classes -> ~ 2 minutes > > recompiling all traits -> ~ 13 minutes > > > > is there any way to recompile all without removing and adding all trait > methods > > for trait users ? Because this touches the changes file (although > recompiling > > shouldn't change the source) and touching the changes file for many > methods > > is pretty slow on windows. > > > > > > nicolai > > >

Nov. 22, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by Dimitris Chloupis

I think its important to have, I have already learned a ton via Slack and I have marked several posts there are favorites so that I wont lose them . The Slack experiment, even though I have been very skeptical at first, has been a huge success and it can easily compete with the importance of the mailing list. Merging the two would be a huge win for our community. On Sat, Nov 21, 2015 at 7:06 PM Stephan Eggermont <stephan(a)stack.nl> wrote: > Should we have a digest from slack to a mailing list? > We are already losing messages > > Stephan > > >

Nov. 22, 2015

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

by Max Leske

If you only need it for yourself you could probably speed things up by doing Smalltalk closeSourceFiles. [ compileâ¦ ] ensure: [ Smalltalk openSourceFiles ]. That will prevent reads and writes from and to the changes / sources files. Of course, that doesnât solve the problem in general. Cheers, Max > On 21 Nov 2015, at 20:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > recompiling all classes -> ~ 2 minutes > recompiling all traits -> ~ 13 minutes > > is there any way to recompile all without removing and adding all trait methods > for trait users ? Because this touches the changes file (although recompiling > shouldn't change the source) and touching the changes file for many methods > is pretty slow on windows. > > > nicolai

Nov. 22, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by Max Leske

I donât think thatâs necessary. Important stuff will still be sent via mail and be documented in issues on fogbugz. Thatâs my personal feeling at least. Cheers, Max > On 21 Nov 2015, at 18:05, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Should we have a digest from slack to a mailing list? > We are already losing messages > > Stephan > >

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Dimitris Chloupis

here is the tricky part , I am willing to bet that the slow down happens because of the stepping of the seconds indicator. The one thing I forgot to mention is that I dont load my images from external files, the images are already converted to method sources , strings , with Peter's IconFactory library. Still the PNGReader class tries to convert those string streams to forms and is where most of the time is consumed. The reason I chose this approach was in hope of a speed up so pharo does not waste time opening and closing files. In the stepping of the seconds indicator I recreate the form in each step , depending on the seconds. I could optomise that part by having all images of the animation loaded into seperate forms during initialisation and just use the reference of the correct form during stepping that should speed things up a lot. Overall 170ms for opening that GUI is not so bad for a dynamic GC language. Taking into account that this is mostly pharo code , unlike python that it would be using a C lib to speed things up. I am a happy Morphic customer :) On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : > > tried with ChronosManager > > > > [ ChronosManager open ] bench > > > > 5.6 per second > > > > it opened around 30 instances and Morphic was crawling. > > > > I profiled it and it reports that it spends a total 170ms which is > > consistent with bench. Around 50ms is spent only for loading the image > > of the secondary panel and from what I have seen loading the images and > > the font accounts around 90% of the time spent and then rest 10% is > > actually morphic + logic. > > If I understand you well, what you have is: > > - ChronosManager takes 170ms to open, including external resources > loading time (which is SSD/HD dependent). > > - The whole world performance degrades with many ChronosManager > instances loaded? (Moving one around probably forces others to refresh > as well). > > What could be nice is to profile rendering time as well (but, if your > first render time is included in the 10% of 170ms you quote, then it is > probably fine). > > Would you like to try benchmarking rendering one ChronosManager instance > when you have 30 instances opened / only one instance opened? > > > So from the looks of it , it looks like Morphic does not perform well > > with loaded images and external files. > > This is a clear win if you cache those (i.e. have a LRU cache holding > forms and fonts, filled upon first load, reused over subsequent loads). > > Thierry > > > > > > > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier > > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > Hi all, > > > > I would like to ask you, all of you, something significant when doing > > GUI coding: > > > > Pay attention to performance! > > > > With the current state of our technology (Morphic, Bloc, whatever > comes > > next) your target should be one hundred milliseconds (100 ms), for > > opening / redisplaying the widget. > > > > Why? > > > > - Because, in 10ms, Morphic can open and layout dozens of Morphs on a > > low-end machine (1.4GHz Celeron). > > > > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the > cpu > > performance of that said Celeron). > > > > - Because you are not to reproduce the past: that your current tools > are > > slow is no excuse. > > > > - Because you now have well designed core widgets (FT) that behaves > in > > O(1) and opens fully loaded in 10's of milliseconds > > > > So, profile and clean your code! Eliminate unneeded caches! Clean > your > > architectures! Avoid or mark slow code and bottlenecks! > > > > And bring numbers when you want to criticize the performance of a > > subsystem... > > > > Thierry > > > > >

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Thierry Goubier

Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : > tried with ChronosManager > > [ ChronosManager open ] bench > > 5.6 per second > > it opened around 30 instances and Morphic was crawling. > > I profiled it and it reports that it spends a total 170ms which is > consistent with bench. Around 50ms is spent only for loading the image > of the secondary panel and from what I have seen loading the images and > the font accounts around 90% of the time spent and then rest 10% is > actually morphic + logic. If I understand you well, what you have is: - ChronosManager takes 170ms to open, including external resources loading time (which is SSD/HD dependent). - The whole world performance degrades with many ChronosManager instances loaded? (Moving one around probably forces others to refresh as well). What could be nice is to profile rendering time as well (but, if your first render time is included in the 10% of 170ms you quote, then it is probably fine). Would you like to try benchmarking rendering one ChronosManager instance when you have 30 instances opened / only one instance opened? > So from the looks of it , it looks like Morphic does not perform well > with loaded images and external files. This is a clear win if you cache those (i.e. have a LRU cache holding forms and fonts, filled upon first load, reused over subsequent loads). Thierry > > > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi all, > > I would like to ask you, all of you, something significant when doing > GUI coding: > > Pay attention to performance! > > With the current state of our technology (Morphic, Bloc, whatever comes > next) your target should be one hundred milliseconds (100 ms), for > opening / redisplaying the widget. > > Why? > > - Because, in 10ms, Morphic can open and layout dozens of Morphs on a > low-end machine (1.4GHz Celeron). > > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the cpu > performance of that said Celeron). > > - Because you are not to reproduce the past: that your current tools are > slow is no excuse. > > - Because you now have well designed core widgets (FT) that behaves in > O(1) and opens fully loaded in 10's of milliseconds > > So, profile and clean your code! Eliminate unneeded caches! Clean your > architectures! Avoid or mark slow code and bottlenecks! > > And bring numbers when you want to criticize the performance of a > subsystem... > > Thierry >

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Dimitris Chloupis

tried with ChronosManager [ ChronosManager open ] bench 5.6 per second it opened around 30 instances and Morphic was crawling. I profiled it and it reports that it spends a total 170ms which is consistent with bench. Around 50ms is spent only for loading the image of the secondary panel and from what I have seen loading the images and the font accounts around 90% of the time spent and then rest 10% is actually morphic + logic. So from the looks of it , it looks like Morphic does not perform well with loaded images and external files. On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi all, > > I would like to ask you, all of you, something significant when doing > GUI coding: > > Pay attention to performance! > > With the current state of our technology (Morphic, Bloc, whatever comes > next) your target should be one hundred milliseconds (100 ms), for > opening / redisplaying the widget. > > Why? > > - Because, in 10ms, Morphic can open and layout dozens of Morphs on a > low-end machine (1.4GHz Celeron). > > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the cpu > performance of that said Celeron). > > - Because you are not to reproduce the past: that your current tools are > slow is no excuse. > > - Because you now have well designed core widgets (FT) that behaves in > O(1) and opens fully loaded in 10's of milliseconds > > So, profile and clean your code! Eliminate unneeded caches! Clean your > architectures! Avoid or mark slow code and bottlenecks! > > And bring numbers when you want to criticize the performance of a > subsystem... > > Thierry > >

Nov. 22, 2015

A plea for responsive coding

by Thierry Goubier

Hi all, I would like to ask you, all of you, something significant when doing GUI coding: Pay attention to performance! With the current state of our technology (Morphic, Bloc, whatever comes next) your target should be one hundred milliseconds (100 ms), for opening / redisplaying the widget. Why? - Because, in 10ms, Morphic can open and layout dozens of Morphs on a low-end machine (1.4GHz Celeron). - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the cpu performance of that said Celeron). - Because you are not to reproduce the past: that your current tools are slow is no excuse. - Because you now have well designed core widgets (FT) that behaves in O(1) and opens fully loaded in 10's of milliseconds So, profile and clean your code! Eliminate unneeded caches! Clean your architectures! Avoid or mark slow code and bottlenecks! And bring numbers when you want to criticize the performance of a subsystem... Thierry

Nov. 22, 2015

Re: [Pharo-dev] opal optimize to do limits

by Levente Uzonyi

On Fri, 20 Nov 2015, ClÃ©ment Bera wrote: > You can use whileTrue: if it's a problem for you not to evaluate the limit at each iteration of the loop. > If you look at OrderedCollection for example, there are implemented differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak uses whileTrue: to iterate over the collection. Hence, if you remove elements from the OrderedCollection while iterating > over it, the behavior is different. One should refrain from modifying collections during iteration. In case of OrderedCollection there's #removeAllSuchThat: to let one safely remove elements from the collection while iterating over it. Levente

Nov. 22, 2015

Re: [Pharo-dev] opal optimize to do limits

by Eliot Miranda

Hi Nicolai, On Sat, Nov 21, 2015 at 10:40 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-11-20 9:58 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> On Nov 20, 2015, at 12:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> Thanks eliot, Clement, >> >> but if the argument for to:do: is not an expression but one of the method >> argument, this >> transformation is not needed. Or still? >> >> >> That's the corollary to what I said. Since method (*) arguments are >> read-only it is safe to use them directly and avoid the transformation. >> One could implement this quickly in the Squeak compiler too :-). How many >> cases have you identified where this matters? Is it very common? >> > > I don't know, but I don't think so. > Recompiling all ~90000 compiled methods, once with opal and once with the > other compiler and comparing > the numbers of tempVars gives a difference of about 400 methods. > Not all 400 differences came from the extra tempvars for the to:do: > transform, and sometimes opal generates code with less temp vars. > Well it's a nice surprise to find out that the Squeak compiler does use a variable directly if it's not assigned to in the block. Thanks to your observation I've simplified the test a little, not scanning for assignments if the variable is a method argument or a block argument and the assignment to block arg preference is not in effect. Anyway, adding extra tempvars for accessing the method arguments seems to > be a bug. > Agreed ;-) (* and with the right preference, block) >> _,,,^..^,,,_ (phone) >> >> >> >> >> >> 2015-11-20 8:31 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> You can use whileTrue: if it's a problem for you not to evaluate the >>> limit at each iteration of the loop. >>> >> >> I don't need this. I just compared some compiled methods bytecodes after >> the latest fix for the wrong frame size calculation. >> For this, I compared opal compilers result with that of the old compiler. >> And I noticed that some methods compiled with >> opal had some "hidden" temps and couldn't explain way:) >> >> >> >>> >>> If you look at OrderedCollection for example, there are implemented >>> differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak >>> uses whileTrue: to iterate over the collection. Hence, if you remove >>> elements from the OrderedCollection while iterating over it, the behavior >>> is different. >>> >>> >>> 2015-11-20 1:34 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Because were to:do: not inlined the expression passed as the to: actual >>>> argument would be evaluated exactly once (bound to the formal argument for >>>> to:) and so assigning to a temporary preserves the semantics in the most >>>> direct way. If the expression has side effects then those side effects >>>> must occur only once. >>>> >>>> Note that were the to: expression merely another variable then the >>>> compiler could only substitute the original variable if it's value could >>>> not change, e.g. in >>>> >>>> exampleToDoArgumentLimitIsExpression >>>> | count sum | >>>> count := 10. >>>> sum := 0. >>>> 1 to: count do: [ :each | sum := sum + each]. >>>> ^sum >>>> >>>> It is ok to use count directly as the limit variable, but in this it is >>>> not: >>>> >>>> exampleToDoArgumentLimitIsExpression >>>> | count sum | >>>> count := 10. >>>> sum := 0. >>>> 1 to: count do: [ :each | sum := sum + each. count := >>>> #somethingElseEntirely]. >>>> ^sum >>>> >>>> _,,,^..^,,,_ (phone) >>>> >>>> > On Nov 19, 2015, at 1:14 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>>> wrote: >>>> > >>>> > What is the purpose of replacing expressions, used as limits in a >>>> > to:do: call with by a new temporary variable? >>>> > >>>> > For example: >>>> > >>>> > OCOpalExamples>>#exampleToDoArgumentLimitIsExpression >>>> > the code is >>>> > >>>> > exampleToDoArgumentLimitIsExpression >>>> > | count sum | >>>> > count := 10. >>>> > sum := 0. >>>> > 1 to: count - 1 do: [ :each | sum := sum + each]. >>>> > ^sum >>>> > >>>> > the decompiled bytecode : >>>> > >>>> > exampleToDoArgumentLimitIsExpression >>>> > | tmp1 tmp2 tmp3 | >>>> > tmp1 := 10. >>>> > tmp2 := 0. >>>> > tmp3 := tmp1 - 1. >>>> > 1 to: tmp3 do: [ :tmp4 | tmp2 := tmp2 + tmp4 ]. >>>> > ^ tmp2 >>>> > >>>> > So, the expression (count - 1) in the to:do: loop is replaced by a new >>>> > temporay (tmp3). >>>> > >>>> > Ok, but why ? >>>> >>>> >>> >> > -- _,,,^..^,,,_ best, Eliot

Nov. 21, 2015