Graphical operations probably slower with NF - moving objects case

[massimo ceraolo]

Slowness in performing graphical operations on model diagrams in OMEdit has always been a weakness of OM.
Although I cannot provide a test, after several days of intensive usage, I think the situation has worsened with NF.

In this ticket, I concentrate on moving objects (and object sets)
Just as an example try this:

• duplicate Electrical-analog-examples-CauerLowPassOPV
• select everything
• click arrow-left

Moving the model representation left takes a huge time: 15s on my laptop! It is near-instantaneous on the same PC in Dymola.
This is very bad. Consider that one usually moves by keyboard instead of mouse-dragging to be more accurate in positioning, but this requires several keystrokes in a row.

There are other merely graphical operations that are too slow for a satisfying programmer's life, but for me, this is the first to be reported.

[Francesco Casella]

@ceraolo, can you please help us pinpointing the root cause:

• perform the operation at some exact known time, based on your PC clock
• open the omeditcommunication.log file and look for operations carried out at that time
• try to pinpoint the API call(s) that took the larger amounts of time and report them

Thanks!

[massimo ceraolo]

To be more precise, I repeated time measuring starting from a freshly rebooted PC, and just-opened OMEdit. This way repeating this ticket's description procedure I measured 22s. This larger time is probably due to the absence of any OMEdit caching but changes nothing about the ticket meaning.

I'll enclose omeditcommunications.log.

I don't know what's happening, but I dare to say that there should be specific APIs for cosmetic operations such as moving, to avoid the more sophisticate OMC actions that occur when "meaningful" (i.e. non-just cosmetic) operations occur.