[Pharo-users] Morphic is super slow

Dimitris Chloupis kilon.alios at gmail.com
Sat Jan 16 03:03:54 EST 2016


Hello Ben :)

First thanks for investing 1 hour of your precious time to look through my
code. I really appreciate it . If there is one thing I love about pharo is
the super amazing community.

Yes definetly my fault as always :D

I did not know about this profiling, I used it for the creating of my
Morphs but it did not occur to me to google like you did and go with
profiling all processes.

A huge thank you to latsaben and the rest of you guys. I downgraded down to
Pharo 4 and again I agree 5 is the unstable version anyway but I loved
using the new tools and could not wait till April for the Pharo 5 release
:)

The problem is battling without documentation is very hard and I have spent
at least 10 hours trying to understand how taskbar works and I still fail.

Your code solves my problem , apart from 1. Loading those pngs is
sloowwwww, one would expect that accesing the files themselves to get the
binary data is what is slow for pharo but no, thats is fast enough. What is
slow , because I profiled this is converting the binary data to  form is
consuming a ton of time. The result is that to load a GUI with only 1 mb of
pngs takes 1 second.

Also with your solution I lose the ability to update my taskbar icon, by
the way the non optimised code I was using is a direct copy from
SystemWindow class, which means that class should be optimised too.

Another problem is the scaling of images, really bad with morphic though
Athens must be better.

Auto completion problems are well knows, sometimes autocompletion does not
show all methods, sometimes autocompletion shows every character you type
so for example ChronosManager open will show
ChronosManager o
ChronosManager op
ChronosManager ope
ChronosMAnager open

Sometimes it shows methods that do not even belong to the class forcing me
to use Spotter to find the correct method. Its a a mess.

I am not abandoning pharo, I love it even with its flaws. But I try to
outsource as much as I can my workflow from pharo to external libraries and
apps that are way more mature and efficient for what I am trying to do.

I always inteded to make Blender work with Pharo, I accomplished that now I
want to make Unreal engine to work with pharo, so I can make a triangle of
love, Blender for asset creation, Unreal for real time rendering of 2d and
3d graphics , Pharo as the brain of the logic and advanced scripting of the
other 2. This is was my dream and goal all along. So I will be moving my
GUI to Unreal that will allow me much more advanced and performance
orientated features that mix 2d with 3d but I will keeping my main logic in
pharo.


On Sat, Jan 16, 2016 at 6:35 AM Ben Coman <btc at openinworld.com> wrote:

> On Sat, Jan 16, 2016 at 7:28 AM, Dimitris Chloupis
> <kilon.alios at gmail.com> wrote:
> > taskbarTask (self valueOfProperty: #noTaskbarTask ifAbsent: [ false ])
> > ifTrue: [ ^ nil ]. ^ nil "TaskbarTask morph: self state: self
> taskbarState
> > icon: self taskbarIcon label: self taskbarLabel"
> >
> > The uncommented part was the one that was slowing me down, its a copy
> from
> > SystemWindow, on a new image of Pharo consumption drops to 15% but still
> > have issues with Nautilus etc.
> >
> > latsabben at Slack also recommended caching which helped also
> >
> > taskbarTask "myTask := nil." myTask ifNil: [ myTask := TaskbarTask morph:
> > self state: self taskbarState icon: self taskbarIcon label: self
> > taskbarLabel ]. myTask label: self taskbarLabel. ^myTask
> >
> > Anyway I decided to port my project to C++ and Unreal Engine because I
> have
> > many issues with Pharo speed wise
>
> See my other post, in about an hour I moved your App from 55% cpu
> usage on my machine to 7%, only 1% above our 6% idle.   We *do* need
> to address that minimum idle, but its at the VM level since in-Image
> profiling shows 90% time in ProcessorScheduler class>>idleProcess.  So
> to me the Image seems not too bad performance wise
>
> > and stability wise with Pharo 5.
>
> Well, you are talking about bleeding edge alpha software.
>
> > Plus many IDE features I miss like proper auto completion etc.
>
> You've probably mentioned this somewhere previously, but in another
> thread could you leave us with a summary of what is missing from auto
> completion.
>
> > To be fair I tried to make custom gui with python and it was even slower
> in
> > the past.
> >
> > So its clear I need a high performance language + API, because I will be
> > building a very heavy GUI (many more animations)  and I would like also
> some
> > fast 3d functionality too.
>
> good luck with it.
> cheers -ben
>
>
> >
> > On Sat, Jan 16, 2016 at 1:07 AM Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> >>
> >>
> >> > On 15 Jan 2016, at 23:30, Dimitris Chloupis <kilon.alios at gmail.com>
> >> > wrote:
> >> >
> >> > taskbar was the problem, damn pharo gui is a huge pain in the hat.
> >>
> >> How so ?
> >>
> >> > On Fri, Jan 15, 2016 at 11:32 PM Dimitris Chloupis
> >> > <kilon.alios at gmail.com> wrote:
> >> > ITs not the step, I removed the step as I said in my first post. Still
> >> > 30% cpu consumption
> >> >
> >> > The images are PNGs and RGBA , 8bit
> >> >
> >> >
> >> > On Fri, Jan 15, 2016 at 10:54 PM Hilaire <hilaire at drgeo.eu> wrote:
> >> > It depends on what you are doing in a step, but 1s step should not
> hurt.
> >> > May be the problem is somewhere else.
> >> > With DrGeo, I noted Athens is faster to BitBlt with bitmap operations
> >> > (in my case, only scaling and displaying a From in a DrGeo canvas).
> >> > Also, do your bitmaps come with 32 bits depth?
> >> >
> >> > --
> >> > Dr. Geo
> >> > http://drgeo.eu
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160116/77907d21/attachment.html>


More information about the Pharo-users mailing list