Smalltalk › Pharo › Pharo Smalltalk Users

Slowness question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Hilaire Fernandes-6

Slowness question

Hi,

Programmed sketch in DrGeo can be animated, for example like the script
bellow.
The "canvas do:" message forks the block so user is not blocked.
At #udpate message the items and views (morph) are recomputed and refreshed
.
Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

Thanks

---8<------
|canvas s stats points|

points :=Array new: 12.
stats := Array new: 12 withAll: 0.

canvas := DrGeoCanvas new.
2 to: 12 do: [:i |
points at: i put: (canvas point: i@0.1).
(points at: i) square; color: Color blue.
s := canvas segment: i@0 to: (points at: i).
s color: Color red].

canvas do: [
1 to: 10000 do: [:i|
s := 6 atRandom + 6 atRandom.
stats at: s put: ((stats at: s)+1).
(points at: s)
name: (stats at: s) asString;
moveTo: s @ ((stats at: s) / 100).
canvas update].
---8<------

--
Dr. Geo http://drgeo.eu

Clément Béra

Re: Slowness question

Igor do you have a clue ?

(I'm not sure Igor is on pharo-users)

Clement

2014-06-04 23:15 GMT+02:00 Hilaire Fernandes <[hidden email]>:

Hi,

Programmed sketch in DrGeo can be animated, for example like the script
bellow.
The "canvas do:" message forks the block so user is not blocked.
At #udpate message the items and views (morph) are recomputed and refreshed
.
Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

Thanks

---8<------
|canvas s stats points|

points :=Array new: 12.
stats := Array new: 12 withAll: 0.

canvas := DrGeoCanvas new.
2 to: 12 do: [:i |
points at: i put: (canvas point: i@0.1).
(points at: i) square; color: Color blue.
s := canvas segment: i@0 to: (points at: i).
s color: Color red].

canvas do: [
1 to: 10000 do: [:i|
s := 6 atRandom + 6 atRandom.
stats at: s put: ((stats at: s)+1).
(points at: s)
name: (stats at: s) asString;
moveTo: s @ ((stats at: s) / 100).
canvas update].
---8<------

--
Dr. Geo http://drgeo.eu

Alain Busser

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

What does the profiler say?

Alain

On Thu, Jun 5, 2014 at 1:15 AM, Hilaire Fernandes <[hidden email]> wrote:

Hi,

Programmed sketch in DrGeo can be animated, for example like the script
bellow.
The "canvas do:" message forks the block so user is not blocked.
At #udpate message the items and views (morph) are recomputed and refreshed
.
Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

Thanks

---8<------
|canvas s stats points|

points :=Array new: 12.
stats := Array new: 12 withAll: 0.

canvas := DrGeoCanvas new.
2 to: 12 do: [:i |
points at: i put: (canvas point: i@0.1).
(points at: i) square; color: Color blue.
s := canvas segment: i@0 to: (points at: i).
s color: Color red].

canvas do: [
1 to: 10000 do: [:i|
s := 6 atRandom + 6 atRandom.
stats at: s put: ((stats at: s)+1).
(points at: s)
name: (stats at: s) asString;
moveTo: s @ ((stats at: s) / 100).
canvas update].
---8<------

--
Dr. Geo http://drgeo.eu

Hilaire Fernandes-6

Re: Slowness question

I did not try yet.

Hilaire

Le 05/06/2014 19:46, Alain Busser a écrit :
> What does the profiler say?
>
> Alain
>

--
Dr. Geo http://drgeo.eu

Sven Van Caekenberghe-2

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

On 04 Jun 2014, at 23:15, Hilaire Fernandes <[hidden email]> wrote:

> Programmed sketch in DrGeo can be animated, for example like the script
> bellow.
> The "canvas do:" message forks the block so user is not blocked.
> At #udpate message the items and views (morph) are recomputed and refreshed
> .
> Before porting DrGeo to Athens, the animation was pretty fast, now it is
> very slow.
>
> Any idea from where it could come from?

I don't know, this is not my area. But I remember a discussion about Morphic updates and Athens where Igor participated in, but I can't find it anywhere. I thought he said doing it that way is very inefficient.

Sorry for the vague answer.

Hilaire Fernandes-6

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

When executing under the profiler the mentioned DrGeo script, I realize
the Profiler window is severely broken:

Part of the windows can't be renderd, profile result can not be properly
read (tiny text zone user can't resize). See screenshot.
Can't see related problem on the bug tracker.

Hilaire

Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
> Before porting DrGeo to Athens, the animation was pretty fast, now it is
> very slow.
>
> Any idea from where it could come from?

--
Dr. Geo http://drgeo.eu

brokenprofiler.jpeg (58K) Download Attachment

Hilaire Fernandes-6

Re: Slowness question

In reply to this post by Sven Van Caekenberghe-2

Right, I remember about it as well.
Once a few morphs are added it get really slower pretty quickly.

The discussion you refer is there:
http://forum.world.st/Redraw-suggestion-for-Athens-tt4750951.html#a4751188

Regarding DrGeo canvas, it does not really need and rely on the change
mechanisme of Morph: model tree is updated in one shot, then the views
are updated in one shot after. But may be there are leftover change in
the used view, not necessary to drgeo but implying unecessary update.

Hilaire

Le 06/06/2014 14:46, Sven Van Caekenberghe a écrit :
> I don't know, this is not my area. But I remember a discussion about Morphic updates and Athens where Igor participated in, but I can't find it anywhere. I thought he said doing it that way is very inefficient.

--
Dr. Geo http://drgeo.eu

Hilaire Fernandes-6

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

I extracted from the buggy profiler window the profile tree of the
execution of this script.

The DrGeo computing part take only a fraction of the CPU time.

Hilaire

Le 06/06/2014 14:55, Hilaire Fernandes a écrit :

> When executing under the profiler the mentioned DrGeo script, I realize
> the Profiler window is severely broken:
>
> Part of the windows can't be renderd, profile result can not be properly
> read (tiny text zone user can't resize). See screenshot.
> Can't see related problem on the bug tracker.
>
> Hilaire
>
> Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
>> Before porting DrGeo to Athens, the animation was pretty fast, now it is
>> very slow.
>>
>> Any idea from where it could come from?
>

--
Dr. Geo http://drgeo.eu

profilingAthens.txt (10K) Download Attachment

stepharo

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

can you open a bug entry.

Stef

On 6/6/14 14:55, Hilaire Fernandes wrote:

stepharo

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

igor is hacking with max on virtualCPU to offer a common abstraction to
both X86 and ARM assembly generation
and nativeboost.

Stef

On 4/6/14 23:15, Hilaire Fernandes wrote:

> Hi,
>
>
> Programmed sketch in DrGeo can be animated, for example like the script
> bellow.
> The "canvas do:" message forks the block so user is not blocked.
> At #udpate message the items and views (morph) are recomputed and refreshed
> .
> Before porting DrGeo to Athens, the animation was pretty fast, now it is
> very slow.
>
> Any idea from where it could come from?
>
> Thanks
>
>
> ---8<------
> |canvas s stats points|
>
> points :=Array new: 12.
> stats := Array new: 12 withAll: 0.
>
> canvas := DrGeoCanvas new.
> 2 to: 12 do: [:i |
> points at: i put: (canvas point: i@0.1).
> (points at: i) square; color: Color blue.
> s := canvas segment: i@0 to: (points at: i).
> s color: Color red].
>
> canvas do: [
> 1 to: 10000 do: [:i|
> s := 6 atRandom + 6 atRandom.
> stats at: s put: ((stats at: s)+1).
> (points at: s)
> name: (stats at: s) asString;
> moveTo: s @ ((stats at: s) / 100).
> canvas update].
> ---8<------
>
>
>

Hilaire Fernandes-6

Re: Slowness question

In reply to this post by stepharo

Hi Steph,

Before I would like to discuss the issue because I don't know if it
belongs to drgeo itlself or Pharo.

What is strange, althought the script execution becomes more and more
slow as more and more items are built, once the sketch is fully
constructed, manipulating the sketch is fast and smooth.

The only things I can add about this script: the construction take place
in a forked process to let the user see the construction as an animation.

I emptied the change/update family of methods in the used morph for
drgeo canvas, it does change the issue.

Hilaire

Le 06/06/2014 18:03, stepharo a écrit :

> can you open a bug entry.
>
> Stef
>
> On 6/6/14 14:55, Hilaire Fernandes wrote:
>> When executing under the profiler the mentioned DrGeo script, I realize
>> the Profiler window is severely broken:
>>
>> Part of the windows can't be renderd, profile result can not be properly
>> read (tiny text zone user can't resize). See screenshot.
>> Can't see related problem on the bug tracker.
>>
>> Hilaire
>>
>> Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
>>> Before porting DrGeo to Athens, the animation was pretty fast, now it is
>>> very slow.
>>>
>>> Any idea from where it could come from?
>
>
>

--
Dr. Geo http://drgeo.eu

Hilaire Fernandes-6

Re: Slowness question

Read: "...it does not change the issue."

Le 06/06/2014 18:19, Hilaire Fernandes a écrit :
> I emptied the change/update family of methods in the used morph for
> drgeo canvas, it does change the issue.

--
Dr. Geo http://drgeo.eu

Ben Coman

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

Hilaire Fernandes wrote:

> Hi Steph,
>
> Before I would like to discuss the issue because I don't know if it
> belongs to drgeo itlself or Pharo.
>
> What is strange, althought the script execution becomes more and more
> slow as more and more items are built, once the sketch is fully
> constructed, manipulating the sketch is fast and smooth.
>
> The only things I can add about this script: the construction take place
> in a forked process to let the user see the construction as an animation.
>
> I emptied the change/update family of methods in the used morph for
> drgeo canvas, it does change the issue.
>
> Hilaire
>
>
> Le 06/06/2014 18:03, stepharo a écrit :
>
>> can you open a bug entry.
>>
>> Stef
>>
>> On 6/6/14 14:55, Hilaire Fernandes wrote:
>>
>>> When executing under the profiler the mentioned DrGeo script, I realize
>>> the Profiler window is severely broken:
>>>
>>> Part of the windows can't be renderd, profile result can not be properly
>>> read (tiny text zone user can't resize). See screenshot.
>>> Can't see related problem on the bug tracker.
>>>
>>> Hilaire
>>>
>>> Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
>>>
>>>> Before porting DrGeo to Athens, the animation was pretty fast, now it is
>>>> very slow.
>>>>
>>>> Any idea from where it could come from?
>>>>

I once had a problem with Announcements being fired too often for the
rendering loop, but apparently my solution wasn't the best.

So I'm just just curious what might happen if somewhere under the
WorldState>>doOneCycleFor: call stack you might store the time "now",
only do a high cost render every 100ms.

cheers -ben

Hilaire Fernandes-6

Re: Slowness question

Le 06/06/2014 19:34, Ben Coman a écrit :

> So I'm just just curious what might happen if somewhere under the
> WorldState>>doOneCycleFor: call stack you might store the time "now",
> only do a high cost render every 100ms.

Can you rephrase I don't understand?

Thanks

Hilaire

--
Dr. Geo http://drgeo.eu

Hilaire Fernandes-6

Re: Slowness question

In reply to this post by stepharo

Oops, I did not realize you were referring to the profiler bug!
Here it is https://pharo.fogbugz.com/f/cases/13309/

Hilaire

Le 06/06/2014 18:03, stepharo a écrit :
> can you open a bug entry.
>
> Stef

--
Dr. Geo http://drgeo.eu

Ben Coman

Re: Slowness question

In reply to this post by Hilaire Fernandes-6

Hilaire Fernandes wrote:

Le 06/06/2014 19:34, Ben Coman a écrit :

So I'm just just curious what might happen if somewhere under the
WorldState>>doOneCycleFor: call stack you might store the time "now",
only do a high cost render every 100ms.


Can you rephrase I don't understand?

Thanks

Hilaire

I was referring to

	 30.2% {8564ms} DrGDrawable(Morph)>>fullDrawOnAthensCanvas:

Perhaps the total accumulation of time includes how often the code is run.
Just as an experiment, wrap the current method something like...
    now := DateAndTime now.
    lasttime ifNil: [ lasttime = 0].
    (now > lasttime + "100ms") ifTrue: [ "do original method" ]

Now the display might flash horribly, but you may be able to observe an effect on responsiveness, and different profile output as a step to fixing. 

cheers -ben