Extremely sluggish performance of OMEdit when browsing MSL and dragging components thereof

[casella]

I have tried the following experiment on my Dell E7440 laptop, i5-4200U dual-core CPU, running OMC r23031 under Windows 7 Pro:

• Start OMEdit: it takes some time, but that's ok.
• Open a New Model: instantaneous action.
• Click on the Modelica package tree: top level packages show up quickly.
• Click on the Mechanics package tree: a few seconds and it shows up.
• Click on the MultiBody package tree: it takes 15 seconds to display the 12 sub-packages with their icons.
• Click on the Joints tree: it takes 1 minute 15 seconds (!!!) to display the 14 components and the three sub-packages.
• Open Modelica.Fluid.Vessels
• Drag one ClosedVolume onto the new model: it takes 25 (!) seconds for the new instance to actually get dropped on the new model diagram. This is particularly annoying as there is absolutely no feedback that anything is going on, unless one turns on the process monitors and sees that omc.exe is taking up a lot of CPU time.

This kind of performance is clearly unacceptable, give the very small amount of information that actually needs to be processed and ferried around between OMEdit and OMC to carry out these tasks. All this time is spent by omc.exe taking up two full logical CPUs out of four. It's nice that we get multi-threading, but to do what?

It seems to me that the implementation of the API functions called by OMEdit to gather the required information (or maybe the way they are called?) is extremely inefficient. Can you please investigate what is OMC doing all this time, and possibly find some fix?

[adeas31]

I have tried the same on my HP Elitebook 8560p, i7-2620M CPU, running OMC r23163 under Windows 7 pro. Note that my results will be different because of different processors and mainly because I am using a version of OMC after #2882 is fixed.

In general this sluggish performance is not directly related to OMEdit (Qt's GUI performance is very fast). It is because OMC instantiates when OMEdit queries the annotations.

If you want to see which OMC API is taking time then check omeditcommunication.log file in your tmp directory.

I ran the above steps and I found this in my log file,

Commands	Time (secs)
getComponentAnnotations(Modelica.Mechanics.MultiBody.World)	9.787
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit)	18.465
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Planar)	9.146
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.UniversalSpherical)	9.435
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.SphericalSpherical)	5.665
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Universal)	4.947

I think the above table tells it all. If one API call takes approx. 10 secs then of course the performance of the client is sluggish.

getComponentAnnotations seems to be the most time consuming API as per my log file details.

[adeas31]

I have also tested the case of dragging ClosedVolume onto a new model. In this case OMEdit sends 197 commands to OMC (the number is huge because Fluid models use a lot of inheritance, it could be very less for simple models). I checked these commands in the log file and the average time taken for these commands is approx 0.2 secs, however there are several commands which are very fast and just takes a fraction of sec so I will say average command time is 0.15 so 197*0.15=29.55

Yes dragging a ClosedVolume onto a new model will take approx. 30 secs. Since OMEdit does the caching of OMC commands so try dragging another ClosedVolume and you will see the component within 2 secs (once OMEdit has all the information from OMC then drawing is very quick).

I will continue my investigation and will try to see if it is possible to reduce the communication between OMEdit and OMC.

[adeas31]

197 commands.......really??? well actually yes but we don't need a lot of information when just dragging the component. OMEdit was fetching the information of parameters, comments, units etc. when the component is dragged. This information is needed only when user opens the parameters window.

In r23196, I have changed the code so that we only fetch the information when its needed. Now dragging is instantaneous action.

My changes somewhat fixes the problem mentioned in comment 2 but in order to improve the performance we need to fix the OMC API issues mentioned in comment 1.

[casella]

Replying to adeas31:

197 commands.......really??? well actually yes but we don't need a lot of information when just dragging the component. OMEdit was fetching the information of parameters, comments, units etc. when the component is dragged. This information is needed only when user opens the parameters window.

In r23196, I have changed the code so that we only fetch the information when its needed.
Now dragging is instantaneous action.

This is quit reasonable fix, but in fact it is not fully solving the problem, only postponing it: what people usually do is that they first drag and drop a component, and then they change its parameters. So they'll wait their 30 seconds on that occasion, which is still quite annoying.

First suggestion: maybe those 197 calls have each a lot of common overhead, that could be spared if API functions were available to return the required information collectively. Could be worth investigating.

Second suggestion: I understand omc can handle multi-threading, and people nowadays have at least two cores on their pc, and will have many more in the future. I think it would be a good strategy to exploit this by pre-fretching all this information in the background as soon as possible, instead of waiting for user interaction and then forcing the user to wait forever. BTW, this has been done by modern compiler GUIs for a long time, I remember 10 years ago NetBeans tried to pre-compile your Java code in advance as you were writing it (exploiting the fact that writing code requires lots of brainpower but very little CPU time), minimizing the waiting time when you wanted to actually run it.

For instance, one thread could be used to handle the operations that require immediate user feedback (and for those, we should minimize the amount of information to be returned by OMC, as you did with the drag-n-drop action), the other thread could run continuously in the background and fetch potentially useful information in advance. Of course, we need some ingenuity and some good user feedback to prioritize the most promising information and fetch it first.

From my point of view, the two things that are most annoying from a user interaction perspective are: waiting for library sub-trees to be loaded, and waiting for the parameter window to open.

The cure for the first issue is to start loading that information in the background as soon as the component is dragged in the diagram.

The cure for the second is a bit less obvious. One option is to use the idle time of the background thread to collect information about all opened packages, using a breadth-first search, though this could be extremely time- and memory-consumimng for large libraries as the MSL, and may clog the background thread with a lot of useless workload. Another possible strategy is that whenever a sub-tree is opened, the background thread immediately starts collecting information about its subtrees one level down - this makes good use of the time users spend looking at the tree and figuring out where their sub-tree of interest is. The foreground thread instead will respond immediately to the user input.

Maybe it would be good to have multiple levels of priority: one thread for immediate end-user feedback, plus several background threads with decreasing priority, so we make sure the CPU is always doing something useful, but we also make sure that tasks with a small chance of being useful do not prevent other more useful tasks to run.

Since OMEdit does the caching of OMC commands so try dragging another ClosedVolume and you will see the component within 2 secs (once OMEdit has all the information from OMC then drawing is very quick).

I noticed this and it's good. Just one comment here: please make sure that the cached information is always up-to-date. For instance, if the model in the library is changed, then all this cached information becomes invalid. Does OMEdit check that? If not, people will run into very serious trouble when they are developing new models and testing them. BTW, once OMC detects some cached info has become invalid, it would be good to re-load it automatically in the background, so that the up-to-date info is there when needed.

[sjoelund.se]

While OMC may be able to handle multi-threading, the CORBA interface does not :(

Also, we would need to tell the compiler we are running a parallel task that is not allowed to change the state (update classes, etc) so that we do not run two such tasks in parallel.

But this would anyway probably require moving omc into the same address space as OMEdit.

Loading sublibraries in OMC is fast (and can be made even faster by using threads; I plan to do this sometime). In OMEdit it is not because it asks information about each class in that library once the library is loaded (instead of a single call returning all of this information).

[casella]

Replying to sjoelund.se:

While OMC may be able to handle multi-threading, the CORBA interface does not :(

I see. But it should be possible to set up multiple CORBA interfaces talking to the same omc, e.g. one for the foreground task and one for the background task, right?

Also, we would need to tell the compiler we are running a parallel task that is not allowed to change the state (update classes, etc) so that we do not run two such tasks in parallel.

Sure. This is also related to the problem of assessing the validity of cached information.

Loading sublibraries in OMC is fast (and can be made even faster by using threads; I plan to do this sometime). In OMEdit it is not because it asks information about each class in that library once the library is loaded (instead of a single call returning all of this information).

Would it be easy to implement such a single-call API function?

[sjoelund.se]

Replying to casella:

I see. But it should be possible to set up multiple CORBA interfaces talking to the same omc, e.g. one for the foreground task and one for the background task, right?

While that is possible, the simpler solution is to just link with libOpenModelicaCompiler.so and talk directly to OMC.
If you have multiple instances of OMC, you need to synchronize the abstract syntax tree between them, so they store the same data.

Loading sublibraries in OMC is fast (and can be made even faster by using threads; I plan to do this sometime). In OMEdit it is not because it asks information about each class in that library once the library is loaded (instead of a single call returning all of this information).

Would it be easy to implement such a single-call API function?

Yes. But CORBA has limits on string lengths (so does the 32-bit OMC version). If you send too large strings it becomes very slow, or it crashes.

[adeas31]

Replying to casella:

Replying to adeas31:

197 commands.......really??? well actually yes but we don't need a lot of information when just dragging the component. OMEdit was fetching the information of parameters, comments, units etc. when the component is dragged. This information is needed only when user opens the parameters window.

In r23196, I have changed the code so that we only fetch the information when its needed.
Now dragging is instantaneous action.

This is quit reasonable fix, but in fact it is not fully solving the problem, only postponing it: what people usually do is that they first drag and drop a component, and then they change its parameters. So they'll wait their 30 seconds on that occasion, which is still quite annoying.

First suggestion: maybe those 197 calls have each a lot of common overhead, that could be spared if API functions were available to return the required information collectively. Could be worth investigating.

Second suggestion: I understand omc can handle multi-threading, and people nowadays have at least two cores on their pc, and will have many more in the future. I think it would be a good strategy to exploit this by pre-fretching all this information in the background as soon as possible, instead of waiting for user interaction and then forcing the user to wait forever. BTW, this has been done by modern compiler GUIs for a long time, I remember 10 years ago NetBeans tried to pre-compile your Java code in advance as you were writing it (exploiting the fact that writing code requires lots of brainpower but very little CPU time), minimizing the waiting time when you wanted to actually run it.

For instance, one thread could be used to handle the operations that require immediate user feedback (and for those, we should minimize the amount of information to be returned by OMC, as you did with the drag-n-drop action), the other thread could run continuously in the background and fetch potentially useful information in advance. Of course, we need some ingenuity and some good user feedback to prioritize the most promising information and fetch it first.

From my point of view, the two things that are most annoying from a user interaction perspective are: waiting for library sub-trees to be loaded, and waiting for the parameter window to open.

The cure for the first issue is to start loading that information in the background as soon as the component is dragged in the diagram.

The cure for the second is a bit less obvious. One option is to use the idle time of the background thread to collect information about all opened packages, using a breadth-first search, though this could be extremely time- and memory-consumimng for large libraries as the MSL, and may clog the background thread with a lot of useless workload. Another possible strategy is that whenever a sub-tree is opened, the background thread immediately starts collecting information about its subtrees one level down - this makes good use of the time users spend looking at the tree and figuring out where their sub-tree of interest is. The foreground thread instead will respond immediately to the user input.

Maybe it would be good to have multiple levels of priority: one thread for immediate end-user feedback, plus several background threads with decreasing priority, so we make sure the CPU is always doing something useful, but we also make sure that tasks with a small chance of being useful do not prevent other more useful tasks to run.

Since OMEdit does the caching of OMC commands so try dragging another ClosedVolume and you will see the component within 2 secs (once OMEdit has all the information from OMC then drawing is very quick).

I noticed this and it's good. Just one comment here: please make sure that the cached information is always up-to-date. For instance, if the model in the library is changed, then all this cached information becomes invalid. Does OMEdit check that? If not, people will run into very serious trouble when they are developing new models and testing them. BTW, once OMC detects some cached info has become invalid, it would be good to re-load it automatically in the background, so that the up-to-date info is there when needed.

Yes, the cached information is only used until the model is not changed. Once the model is changed OMEdit discards the cached information.

[sjoelund.se]

Replying to adeas31:

Yes, the cached information is only used until the model is not changed. Once the model is changed OMEdit discards the cached information.

Do you also handle the case that you invalidate all models that depend on some model that was updated?

[sjoelund.se]

Milestone changed to 1.9.3 since 1.9.2 was released.

[ceraolo]

Just a new measure.
If I double-click (on my recent i5-3.3 GHz/8GB machine) onto an instance of Modelica.Electrical.Machines.SynchronousInductionMachines.SM:PermanentMagnet,
the window containing the parameters needs 31s to display the first time.
The second time is much better (1.5s)

Tested on r25570.

[sjoelund.se]

Moved to new milestone 1.9.4

[casella]

The status has still not changed much: the issue raised in the last bullet of the original description has been addressed (because the waiting time has been postponed to the time the parameter window is loaded). But it still takes over 2 minutes to access the multibody Joint model. This shouldn't really be the case, since the only information that is needed to perform this operation is the class hierarchy and the icon graphics annotation.

[ceraolo]

It seems that the situation is worsening.
I made a test on OMEdit connected to OpenModelica v1.9.4-dev.beta1-42-g0c39bf6.
My system is a 8GB, i5-4590 CPU, 3.3 GHz clock, Win10 PC.

• time to open Multibody package tree: 25 s
• time to open Joints package tree: >5' (then I gave up)

[sjoelund.se]

Can you attach an OMEdit log where you tried this out? (/tmp/OpenModelica_marsj/OMEdit/omeditcommunication.log or similar)

I suspect OMEdit could be calling the diff API for every small update when dragging components, but it could do all of the move/resize operations in OMC and only call the API when a different operation is performed (or waiting longer, but the longer you wait, the more whitespace changes might be introduced).

[adeas31]

I provided the reason in my very first comment. I am just copy pasting it here again,

Commands	Time (secs)
getComponentAnnotations(Modelica.Mechanics.MultiBody.World)	9.787
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit)	18.465
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Planar)	9.146
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.UniversalSpherical)	9.435
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.SphericalSpherical)	5.665
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Universal)	4.947

I think the above table tells it all. If one API call takes approx. 10 secs then of course the performance of the client is sluggish.

[casella]

I just opened #3679 on this specific topic, and marked it as blocker.

Once #3679 is solved, we can close this ticket if there are no other obvious bottlenecks.

[adrpo]

This happens because the MB library has annotations containing parameters so we do instantiation.

[casella]

But why should it take this long to instantiate the World model or the planar joint model? From the testsuite reports, the entire RobotR3 model takes 5 seconds to flatten. This model contains a World model, 6 joint models, 6 body models, plus a lot of other stuff. Why should instantiating one of these models by itself take twice as much time than instantiating all of them?

Are you sure that the API is not instantiating everything for each single annotation?

[ceraolo]

Even though I understand it is obsolete after today's discussion, I wanted to enclose the log asked for by Martin.
Unfortunately did not succeed in finding that file. :-(
However I will follow this ticket and #3679, since they are very important for OM's quality. I agree with the high priority given to them.

[ceraolo]

Timing update using the same PC that I've used four days ago:

• time to open Multibody package tree: 2.75 s
• time to open Joints package tree: 21.7 s

This is an excellent improvement over four days ago. However, IMO, it is something that still needs to work on: from the final user perspective waiting 22 seconds to "open a tree branch" is too much.

[sjoelund.se]

Milestone pushed to 1.9.5

[ceraolo]

The situation has worsened over the last year.
In a not-very-large one-file library of mine (318 kB), the same I used in recent timings in ticket #3318, opening a model used to require 4s on r25516 (more than one year old), while in the more recent builds, either 32 and 64 bits requires about 20s.

[sjoelund.se]

Milestone renamed

[ceraolo]

I think the quality of OM 2.0 deserves an acceptable user experience.
Waiting several seconds to open models can be a real pain.
I think that at least the quasi-reasonable speed of last year's version should be recovered (see. comment 23).
Therefore I think this ticket should become a blocker for 2.0.

[ceraolo]

I don't know what miracle at Dassault's were able to do with Dymola: they cache the whole MSL in less than 3s, and then any "folder" (i.e. MSL sub-package), and any model can be open nearly instantly.

I think that ten times that time is a reasonable target for OM.
However, as AFAIK OMEdit does not do any caching, and to compare OM times with Dymola's, maybe one needs to manually open all folders (i.e. MSL sub-packages) in package browser, and all the models in a view (e.g. diagram view); then sum up all the times.

However, to have a rough idea of where we are now, we can note that opening with OMEdit Modelica.Mechanichs.Multibody.Joints (just to have the list of the contained models) we need on a normal computer around 40 s.)
It easy to estimate that to do all Dymola does in those 3s, at least ha few hundreds of secs are needed by OM.

[casella]

Replying to casella:

I just opened #3679 on this specific topic, and marked it as blocker.

Once #3679 is solved, we can close this ticket if there are no other obvious bottlenecks.

For the time being, until we have a faster front-end providing faster instantiation, we could omit displaying the connectors and only display the icon's graphical annotation in the package tree.

If I understand correctly, this would mean that OMEdit could skip the calls to getComponentAnnotations entirely, which take a large part of the time needed to open a package tree.

After all, the connectors in the icons of the package browser are 1-2 pixels wide, IMO we can sacrifice some accuracy of representation there, if the trade-off is a 5-10X reduction of the time needed to browse the package tree. The important info in that context is the class name, the (very small) icon is just a hint. Besides, when conditional connectors are involved, the graphical representation of connectors is wrong anyway, see #2081.

What do you think?

[casella]

Status update: I have the distinct feeling that the situation has worsened further in the last few weeks, though I cannot point out exactly when it happened. I report the results of three test cases.

Case 1

It now takes 36 seconds on my PC to open the Modelica.Mechanics.MultiBody.Joints subtree, compared to the 22 seconds reported in #3679 six months ago. The functions taking more time are:

Commands	Time (secs)
getIconAnnotation(Modelica.Mechanics.MultiBody.Joints.Revolute)	1.5
getIconAnnotation(Modelica.Mechanics.MultiBody.Joints.Prismatic)	1.5
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.RevolutePlanarLoopConstraint)	1.5
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Prismatic)	1.5
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Cylindrical)	3.1
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Universal)	3.2
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.Planar)	4.2
getComponentAnnotations(Modelica.Mechanics.MultiBody.Joints.FreeMotion)	2.5

Case 2

Opening the ThermoPower.Water subtree takes 200 s. The champion function calls here are:

Commands	Time (secs)
getComponentAnnotations(ThermoPower.Water.PressDrop)	17.4
getComponentAnnotations(ThermoPower.Water.BaseClasses.Flow1DBase)	14.4
getComponentAnnotations(ThermoPower.Water.FlowJoin)	18.2
getComponentAnnotations(ThermoPower.Water.FlowSplit)	16.2
getComponentAnnotations(ThermoPower.Water.BaseClasses.ValveBase)	18.8
getComponentAnnotations(ThermoPower.Water.Pump)	18.7

Case 3

The worst case is the following: opening the Modelica.Media.Air takes 20 seconds, of which 7 are taken by getComponents(Modelica.Media.Air.SimpleAir). If I now try to open the ReferenceMoistAir package, OMC chugs along for 1m20s, allocates 400+ MB extra memory, then crashes. Unfortunately Windows is a bit lazy at flushing the buffer on the omedicommunication.log, so I have no idea which function call actually causes this.

Conclusions

I don't think we can wait until we get the new front end to tackle this problem. It will take a few more months and one or two more releases before the new front end is complete and robust enough to take over the old one. In the meantime, we need to find some hack to get more acceptable performance.

If I am not mistaken, I understand that most of the time is spent doing instantiation to get the connector annotations via getComponentAnnotation. This probably explains the humongous time spent with the ThermoPower models, as their connectors contain Modelica.Media stuff, which takes forever to instantiate. As the connectors are hardly visible in the library browser, the trade-off between accuracy in the icon rendering and the time spent doing that clearly suggest to forget about the connectors.

I would suggest that for the time being we skip getting the component annotations and only make do with the icon annotation. The rendering of the icons will be slightly less accurate, but that is a minor issue compared to waiting minutes for them to show up, or crashing OMEdit.

Adeel, would you mind trying that out ASAP? This is also critical for the forthcoming 1.11 release.

[adeas31]

b91a3a1/OMEdit does more or less what you want.
OMEdit only fetches the components & their annotations once. I just updated the code to fetch when we really need it e.g., drawing a component on a diagram view.

Note that you still might be able to see connectors in the Libraries Browser in some cases. For example, load OMEdit, browse to Modelica->Electrical->Analog->Examples, open ChuaCircuit example by double clicking on it. Now Expand Modelica->Electrical->Analog->Basic, you will see connectors for Ground, Resistor etc. The reason is we have already loaded them as components of ChuaCircuit example.

I personally don't like this workaround because it gives mixed view in Libraries Browser. I think we should fix frontend stuff ASAP instead of doing workarounds.

[ceraolo]

Today I made some tests on OM 1.11.0-dev276.
Opening menus, such as Mechanics.Multibody.Joints is much faster (5x speedup over dev79).
Other operations are still much slower than used to be years ago.
Opening the attached simple "SMAChopper.mo" is around 3 times slower than on r25516.

[adeas31]

Replying to ceraolo:

Today I made some tests on OM 1.11.0-dev276.
Opening menus, such as Mechanics.Multibody.Joints is much faster (5x speedup over dev79).
Other operations are still much slower than used to be years ago.

Of course because we are only postponing the operations.

Opening the attached simple "SMAChopper.mo" is around 3 times slower than on r25516.

I would say its unfair to compare a 20 months old OMEdit with the current one. There are several things that OMEdit is doing now compared to r25516.

[ceraolo]

I would say its unfair to compare a 20 months old OMEdit with the current one. There are several things that OMEdit is doing now compared to r25516.

I understand this. It was just to show how things were going two years ago.
AFAIK the difference in times do not depend on OMEdit, but on how OMC responds to its inputs.

Since I use OM for teaching I tend to put myself in student's position. In our classrooms we have computers that are a few years old. Students will not consider acceptable a tool that will require waiting 10 seconds just to open a model.
Since I want to promote OM strongly, to avoid this bad impact, up to last spring I've used OM r25516 in classrooms. That's a pity since OM is much more powerful now.
Now opening tree branches has improved dramatically. Opening models containing complex MSL submodels such as my example is still much slower than how it used to.

[casella]

I confirm that Adeel's commit behaves as planned. The time to open the MultiBody.Joints tree and the ThermoPower.Water tree in the library browser has been reduced to a few seconds. I guess this is all we can get for 1.11. I agree with Adeel that this is somewhat ugly, but IMHO getting a slightly less accurate graphical representation in 4 seconds is uncomparably better than getting a more accurate one in four minutes. After all, what really matters in the library browser are the class names, not the icons - those are really needed in the diagramss only.

This ticket is now marked as a blocker for 2.0.0, and I think we now have to rely on a faster front-end to solve this issue in a satisfactory way. As soon as we have that, I would revert Adeel's commit.

In the meantime, there might be a further optimization possible. Rendering the diagram of complex models with instances of many different classes, as well as rendering a very crowded package tree, takes lots of time, because their connectors need to be instantiated to get their graphical description. This is currently done in a sequential fashion. I understand the instantiation starts from scratch each time. Would it be possible to exploit multiple CPUs and have multi-threaded instantiation? This could improve the performance by a factor 4 or more on modern PCs, also when we finally get a faster front-end.

Would that be possible with the current OMC/OMEdit architecture?

[adrpo]

Commit: 4fc6fb7/OMCompiler shaves about 5 (out of 15) seconds from loading SMAChopper.mo.

[ceraolo]

Good news!
Thank you for still spending time on this with current OM, even though important changes are expected from the new frontend.
This result will allow me to use the new OM for next semester's course, instead of the aging r25516.
I will make a few tests with real-life models that I use for teaching, and share the results (still comparisons with r25516) on this ticket.

[sjoelund.se]

Replying to casella:

Would that be possible with the current OMC/OMEdit architecture?

Yes, OMEdit could use multi-threading to improve performance. But more important would be to fix all the NULL pointer exceptions and corrupted Qt data structures that currently make OMEdit almost unusable on Linux. (Happens mostly when new models are added, text is edited, etc; after some time, package icons in MSL become a simple P and you know the crash is imminent).

[casella]

Replying to sjoelund.se:

Replying to casella:

Would that be possible with the current OMC/OMEdit architecture?

Yes, OMEdit could use multi-threading to improve performance.

Good. I'll keep this in mind if the new front end is not fast enough :)

But more important would be to fix all the NULL pointer exceptions and corrupted Qt data structures that currently make OMEdit almost unusable on Linux. (Happens mostly when new models are added, text is edited, etc; after some time, package icons in MSL become a simple P and you know the crash is imminent).

Andrea is currently using OMEdit 8 hours a day on Linux, to develop a new library. The good news is that OMEdit is actually usable for this task (provided you save often, see below). The bad news is that he reported to me that OMEdit crashes every now and then, which is of course not good at all. So far he hasn't sent any automatic crash report, I advised him to do so. One should have already been sent by now. I hope it has reached the developers.

Is there any systematic way to catch all these problems and report them automatically, so Adeel knows what he needs to fix?

[ceraolo]

I have an example that crashes (on my PC) every time the following simple sequence is made:

1) open OMEdit
2) load TestCrash.mo
3) open and run IdTwoPWM
4) while remaining in Plottting perspective, acting on the variables browser change the parameter "Fcar" inside pwmPulser from 1000 to 2000, key "Enter" and and click on the Re-simulate button
=> CRASH

Tested on Win10 using OMEdit v1.12.0-dev-27-gce0dd87 (64-bit)
Connected to OpenModelica v1.12.0-dev-38-g8c0a156 (64-bit)

[ceraolo]

I would say its unfair to compare a 20 months old OMEdit with the current one. There are several things that OMEdit is doing now compared to r25516.

Sorry for still considering as reference r25516: as I said, it is the one I've been using for two years satisfactorily for teaching: I know it well, including a few critical bugs, so can tell my students what to take care of.

Today I've made some speed tests, with an OM version that includes the fix mentioned in comment 34. I tested small models that I use for teaching (they require just a few seconds to build and simulate).
The results indicate that today's version of OM nightly build for windows requires opening times are between 2.5 and 12 times the times I used to have with r25516.
In one case (which I can supply in case of need) with today's OM I measured a model opening time of 35s, while, on the same PC, using r25516 it is 2.9 s.

Version used (under win10):
OMEdit v1.12.0-dev-27-gce0dd87 (64-bit)
Connected to OpenModelica v1.12.0-dev-38-g8c0a156 (64-bit)

[adrpo]

@ceraolo: i don't think is unfair, i think we should actually do it and strive to improve. can you send me the 35s model to me via email if is not public?

[ceraolo]

It is the file "FullModel" inside the package Test32s.mo that I'm going to attach.
I confirm the above timings on my PC (~3s vs ~35s).

[adrpo]

For me rendering the FullModel inside Test35.mo takes ~9 seconds but I guess this is due to my new quad core laptop (we only use parallelization for loading files and for GC) which is really fast. I'll look a bit what's the holdup.

[ceraolo]

Yes. Previous tests I made were on my Home PC, that is four years old (and similar to those I use in classroom). On my one-month old University PC I get ~9s as well.

[casella]

This should be fixed with the new-front-end-based API in 1.13.0

[casella]

Rescheduled to 1.14.0

[casella]

After five years, I'm retrying the same experiment that was originally reported, using a Lenovo X1 Carbon laptop with a quad-core i7-8550U CPU, running OpenModelica v1.14.0-dev-26506-gd1598f762c (64-bit) under Windows 10 pro. I set -d=nfAPI,newInst.

• Start OMEdit: it takes some time, but that's ok.
• Open a New Model: instantaneous action.

Same as before.

• Click on the Modelica package tree: top level packages show up quickly.

Same as before.

• Click on the Mechanics package tree: a few seconds and it shows up.

Same as before.

• Click on the MultiBody package tree: it takes 15 seconds to display the 12 sub-packages with their icons.

It now takes about 1 second.

• Click on the Joints tree: it takes 1 minute 15 seconds (!!!) to display the 14 components and the three sub-packages.

It now takes less than 2 seconds.

• Open Modelica.Fluid.Vessels
• Drag one ClosedVolume onto the new model: it takes 25 (!) seconds for the new instance to actually get dropped on the new model diagram. This is particularly annoying as there is absolutely no feedback that anything is going on, unless one turns on the process monitors and sees that omc.exe is taking up a lot of CPU time.

It now takes less than 3 seconds the first time, virtually instantaneous for subsequent instances.

I'm happy to finally close this ticket for good. The performance can be further improved, but while it used to be really unacceptable, it is now more than decent.