Slowness and error in OMEdit error when resizing

[massimo ceraolo]

In some cases resizing of a model in diagram view is very slow.
In the latest nightly build it even creates a huge error message.

I've tested the behaviour using two different versions:
v1.9.4-dev.beta1-101
v1.9.4-dev.beta2-99

Steps to reproduce (using EHPT.mo):
1) load EHPT in OMEdit
2) select FullVehicles|PSecu1
3) using the mouse slightly resize the icon of the large connector EHPT.SupportModels.Conn d
4) OMEdit hangs for a few seconds (both the above versions), then (only the above beta2 version) issues, in the message browser, the huge message (13915 lines) reported in ErrorMessage.txt.

I wonder why resizing is so slow. From my viewpoint it could be an operation carried out directly by OMEdit, without OMC interaction, so I expect it to be very fast.
Whatever the mechanism, the final user expects resizing to be fast since it appears to be just a graphical operation.

In the latest beta the additional issue of the reported error message has appeared.

For me the slowness makes the priority of this ticket "high"; the error message in the beta requires a "critical" priority. That's why I choose the latter.

[Adeel Asghar]

I wonder why resizing is so slow. From my viewpoint it could be an operation carried out directly by OMEdit, without OMC interaction, so I expect it to be very fast.
Whatever the mechanism, the final user expects resizing to be fast since it appears to be just a graphical operation.

OMEdit's resizing of the Graphical objects is very fast. But we need to sync the updated information with OMC. So OMEdit first do the resizing of the Graphical object and then sens the updated information of the object to OMC. In your case the diff algorithm is failing that is why I assigned it to Martin to have a look.

[Martin Sjölund]

And it's slow because you are working with a huge package.mo :) Before Adeel changes that, some operations will be slow. Note that for simple things like resizing, OMEdit should do this work in a thread in the background and possibly queue up operations (all resize, move, graphical annotation things could be queued up in the background). At least on Linux :)

[massimo ceraolo]

OMEdit's resizing of the Graphical objects is very fast. But we need to sync the updated information with OMC.

May I ask why OMC should be aware about the icon size?
Since this information is only of graphical type cannot it be confined to GUI (i.e. OMEdit)?
Would this be possible, the delay and error mentioned in this ticket would instantly disappear.

[Martin Sjölund]

Replying to ceraolo:

May I ask why OMC should be aware about the icon size?
Since this information is only of graphical type cannot it be confined to GUI (i.e. OMEdit)?
Would this be possible, the delay and error mentioned in this ticket would instantly disappear.

I agree, but OMEdit was designed around letting OMC handle the Modelica text (OMEdit does not know where the annotation is or how to update it, so it asks OMC). Any update to the text is sent to OMC, and then in order to not change the text OMC is asked to merge its internal AST with the actual Modelica code that exists (this is relatively slow, but can be done in the background).

[massimo ceraolo]

Replying to sjoelund.se:

I agree, but OMEdit was designed around letting OMC handle the Modelica text (OMEdit does not know where the annotation is or how to update it, so it asks OMC).

This explains that a lot of operations that one would expect to be immediate require some time to perform. Another example is opening a tree branch (see #2960).
I understand from your words that more background updating of OMC from OMEdit is planned, and this would increase speed. Naturally, background operations are still operations, and cpu time is consumed even if in background.

I also understand from your words that the design of OMEdit you mention cannot be changed, because of adverse cost/benefit ratio.

I'm not able to discuss effectively about this choice; however, at least from my standpoint, it seems a bit tricky, and indeed it has caused that, after several years of development, working with OMEdit appears still "gummy", especially in comparison with other tools.

I mean, OMEdit and and OMC are great for me. But newbies such as my students) immediately note, and maybe complain about, how slow are operations perceived as being very simple such as opening a tree or resizing an icon.

[Martin Sjölund]

Milestone pushed to 1.9.5

[massimo ceraolo]

I tried the same resizing on my one-year-plus old OM r25516 and resizing speed is absolutely normal (i.e. quasi-instantaneous), and no error occurs.

[Martin Sjölund]

Milestone renamed

[massimo ceraolo]

I think this issue must be considered a blocker for release 2.0.
Considering comment 9 there must be an easy solution.

I will thus change target and priority.

[Francesco Casella]

This should be fine with 1.13.0. We can move it to 1.14.0 if there are good reasons to do so.

[Francesco Casella]

Rescheduled to 1.14.0

[Francesco Casella]

@ceraolo, can you please check this with -nfAPI and close the ticket if the performance has improved enough?

Thanks!

[massimo ceraolo]

Yes, it has improved a lot.
I see that resizing is now cached, so if we resize a lot actual lag occurs only after we finish. This is a much awaited and very welcome improvement.
I'm going to close this ticket.