On the performance of our browsers... THEY TICK!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

On the performance of our browsers... THEY TICK!

marcel.taeumel
Hi, there.

Our browsers (or rather all tools) are stepping. That's bad. 

See for yourself in #updateListsAndCodeIn: or put a "Transcript showln: #verify" in PluggableListMorph >> #verifyContents. That's why we have to be very careful to add anything new to our tools. Here, #verifyContents makes a full list fetch from the model ... EVERY SECOND!

Note this:
1) We have a system change notifier to respond to code changes in our code-centric tools.
2) We have #changed:/#update: to keep the GUI up-to-date in our other ToolBuilder tools/applications.
3) We should get rid of Object >> #stepIn:, #stepAt:in:, #modelWakeUpIn:, #updateListsAndCodeIn:.

It might be a legacy from old MVC times. I don't know. It is not required anymore.

Best,
Marcel

P.S.: Also see SystemWindow >> #stepTime and all implementors of #stepTimeIn:. ;-)
P.P.S.: Only our Inspector needs it since we have no clue what "changed" means for an arbitrary object.


Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

David T. Lewis
On Sun, Jan 21, 2018 at 09:46:46AM +0100, Marcel Taeumel wrote:

> Hi, there.
>
> Our browsers (or rather all tools) are stepping. That's bad.??
>
> See for yourself in #updateListsAndCodeIn: or put a "Transcript showln: #verify" in PluggableListMorph >> #verifyContents. That's why we have to be very careful to add anything new to our tools. Here, #verifyContents makes a full list fetch from the model ... EVERY SECOND!
>
> Note this:
> 1) We have a system change notifier to respond to code changes in our code-centric tools.
> 2) We have #changed:/#update: to keep the GUI up-to-date in our other ToolBuilder tools/applications.
> 3) We should get rid of Object >> #stepIn:, #stepAt:in:, #modelWakeUpIn:, #updateListsAndCodeIn:.
>
> It might be a legacy from old MVC times. I don't know. It is not required anymore.

It is not a legacy of MVC. I put an "OSProcess trace" in PluggableListView>>verifyContents,
and the updates are efficient and happen as you would expect. In Morphic, ugh! we should
fix it as you say.

I have not really looked into it, but I suspect that most of the necessary #changed:
notifications are already in place, at least for things like browsers and debuggers
that are fully supported in MVC. So it may be just a matter of adding #update:
handlers in Morphic "views" so that the existing change notifications are handled
there, rather than relying on stepping.

Many of the #update: handlers seem to be already in place, so perhaps the stepping
is just a safety net that never got removed?

Dave

>
> Best,
> Marcel
>
> P.S.: Also see SystemWindow >> #stepTime and all implementors of #stepTimeIn:. ;-)
> P.P.S.: Only our Inspector needs it since we have no clue what "changed" means for an arbitrary object.
>


Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

timrowledge
A lot of Morphs simply fetch & re-render new info at every tick (or at least, they used to). For some case that is actually proper (think Dave N Smith’s ancient crawling BlobMorph).

Some got a bit smarter and at least compared the new info to the old before rendering new stuff. Of course, sometimes that involves comparing something a bit more complex than a 10 character String, so not all that smart. And sometimes even simply fetching the new info involves proxies transforming into large amounts of data obtained fro a slow server somewhere, or a colossal list being pointlessly rebuilt.

Getting everything up to date and using #changed etc so morphs only update when they plausibly need to would be a nice thing for slower machines like Pis. We’ll need to have something that considers all the browsers to be its dependents so that when a code change is made that would affect a browser other than the active one we can have the change broadcast to everyone properly. And it would be nice for it to be able to be pretty specific about the change so something a bit more efficient than ‘redraw everything’ can be used. The current CodeHolder>>#updateCodePaneIfNeeded and CodeHolder>>#didCodeChangeElsewhere arrangement doesn’t look particularly nice.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MAW: Make Aggravating Whine



Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

David T. Lewis
On Sun, Jan 21, 2018 at 10:46:59AM -0800, tim Rowledge wrote:
> A lot of Morphs simply fetch & re-render new info at every tick (or at least, they used to). For some case that is actually proper (think Dave N Smith???s ancient crawling BlobMorph).
>
> Some got a bit smarter and at least compared the new info to the old before rendering new stuff. Of course, sometimes that involves comparing something a bit more complex than a 10 character String, so not all that smart. And sometimes even simply fetching the new info involves proxies transforming into large amounts of data obtained fro a slow server somewhere, or a colossal list being pointlessly rebuilt.
>
> Getting everything up to date and using #changed etc so morphs only update when they plausibly need to would be a nice thing for slower machines like Pis. We???ll need to have something that considers all the browsers to be its dependents so that when a code change is made that would affect a browser other than the active one we can have the change broadcast to everyone properly. And it would be nice for it to be able to be pretty specific about the change so something a bit more efficient than ???redraw everything??? can be used. The current CodeHolder>>#updateCodePaneIfNeeded and CodeHolder>>#didCodeChangeElsewhere arrangement doesn???t look particularly nice.
>

That sounds right. If I comment out the body of CodeHolder>>stepIn: so that
it no longer callse #updateListsAndCodeIn: when stepping, the browsers continue
to work as expected, so the basic MVC style updates are workin in the browsers.
However, if I open a versions browser and use it to revert a method, then
the corresponding code pane in another browser no longer gets updated.

It looks like the stepping updates are there to ensure that open browsers
get updated even though we do not (yet) have the "something that considers
all the browsers to be its dependents" part implemented.

If it is true that the stepping updates are being done primarily to ensure
updates for all browsers within a Morphic world, and if it is also true
that some sort of registry is required, then it might make sense for the
current world to be responsible for keeping the registry, such that change
notifications would be delivered to browsers within the current world, and
not to all browsers in all of the other Morphic projects that may exist
in an image.

But I have a feeling I am overlooking something obvious. Isn't there some
more global notification mechanism already present in SystemOrganizer or
SystemNavigation or some such thing?

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

Stéphane Rollandin
> If it is true that the stepping updates are being done primarily to ensure
> updates for all browsers within a Morphic world, and if it is also true
> that some sort of registry is required, then it might make sense for the
> current world to be responsible for keeping the registry, such that change
> notifications would be delivered to browsers within the current world, and
> not to all browsers in all of the other Morphic projects that may exist
> in an image.
It is common for me to have browsers open on the same class across
different projects, so I would appreciate if all browsers were updated.

Actually, I have already be bitten by old code still being displayed as
current in a browser. I do not remember the details though, but it could
involve swapping projects.


Stef

Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

David T. Lewis
On Sun, Jan 21, 2018 at 09:08:32PM +0100, St??phane Rollandin wrote:

> >If it is true that the stepping updates are being done primarily to ensure
> >updates for all browsers within a Morphic world, and if it is also true
> >that some sort of registry is required, then it might make sense for the
> >current world to be responsible for keeping the registry, such that change
> >notifications would be delivered to browsers within the current world, and
> >not to all browsers in all of the other Morphic projects that may exist
> >in an image.
> It is common for me to have browsers open on the same class across
> different projects, so I would appreciate if all browsers were updated.
>
> Actually, I have already be bitten by old code still being displayed as
> current in a browser. I do not remember the details though, but it could
> involve swapping projects.

Stef,

Of course you are right, they do all need to be updated. Sorry that was
a bad idea, please disregard.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: On the performance of our browsers... THEY TICK!

marcel.taeumel
Hi, there.

The subscribe/update-code for our system change notifier is NOT in place for CodeHolder and its subclasses. That would be a first step. "step" ... ha ha ... :-)

I suppose that this stepping is not related to morph updates in general but only to ToolBuilder and SystemWindow. If you take a look at #updatablePanes, you can trace it.

Please do not confuse this issue with re-drawing. Morphic does not tick to draw. Only our pluggable widgets that are requested to update their contents frequently might trigger a re-draw --- but only if contents change. ;-)

Best,
Marcel

Am 21.01.2018 21:25:03 schrieb David T. Lewis <[hidden email]>:

On Sun, Jan 21, 2018 at 09:08:32PM +0100, St??phane Rollandin wrote:
> >If it is true that the stepping updates are being done primarily to ensure
> >updates for all browsers within a Morphic world, and if it is also true
> >that some sort of registry is required, then it might make sense for the
> >current world to be responsible for keeping the registry, such that change
> >notifications would be delivered to browsers within the current world, and
> >not to all browsers in all of the other Morphic projects that may exist
> >in an image.
> It is common for me to have browsers open on the same class across
> different projects, so I would appreciate if all browsers were updated.
>
> Actually, I have already be bitten by old code still being displayed as
> current in a browser. I do not remember the details though, but it could
> involve swapping projects.

Stef,

Of course you are right, they do all need to be updated. Sorry that was
a bad idea, please disregard.

Dave