+1

Lorenzo

Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Dimitris Chloupis
Inviato: domenica 22 novembre 2015 14:56
A: Pharo Development List
Oggetto: Re: [Pharo-dev] A plea for responsive coding

because making something work for me comes way before making something work fast.

On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo@free.fr> wrote:

But why don't you manipulate Forms instead of PNGs. Converting from PNGs to Forms should be done only once.

Stef

Le 22/11/15 11:53, Dimitris Chloupis a ��crit :

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@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@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
>