Opened 9 years ago

Last modified 7 years ago

#3823 accepted defect

Store less information in ElementSource

Reported by: Adrian Pop Owned by: Adrian Pop
Priority: high Milestone: Future
Component: Frontend Version:
Keywords: Cc: Martin Sjölund

Description

We store too much information in ElementSource for components and equations and it takes up a lot of memory. We should be able to disable parts of that depending on a flag.

Partial work has been already done here:
https://github.com/OpenModelica/OMCompiler/pull/657

Change History (8)

comment:1 by Adrian Pop, 9 years ago

Cc: Martin Sjölund added
Owner: changed from somebody to Adrian Pop
Status: newaccepted

comment:2 by Martin Sjölund, 9 years ago

I thought about at the same time changing the Flags.mo from -d=infoXmlOperations to -g=none|xxx?|full where the xxx is what we have today. One problem with our structure is that we have like... 7 elements in the element source which are all updated (things like types/paths are updated more often), so it is like 7*10 updates. Which is why I also considered having a DAE.MINIMALSOURCE(), DAE.XXXSOURCE(), and DAE.FULLSOURCE() for the different levels of debugging flags. But for starters, we should figure out which ElementSource fields can be ignored without breaking simulations.

comment:3 by Martin Sjölund, 9 years ago

Oh, and createElementSource is calling some rather expensive functions as well. First, we call:

source = ElementSource.createElementSource(info, FGraph.getScopePath(env), PrefixUtil.prefixToCrefOpt(pre), SOME((c1_1,c2_1)), NONE());

Which creates a tuple, SOME(), a prefix to cref and a path from an environment. These might not all be needed. Then createElementSource creates an empty SOURCE and adds these fields one at a time. And then later on, updates the fields. This is all very slow :(

comment:4 by anonymous, 9 years ago

Maybe solving this will impact positively on the time needed to open models and trees in packages in OMEdit?
That would be a boon since today OM compilation and simulation speeds are satisfactory in most cases, while first opening of models is dramatically slower than with Dymola.

comment:5 by Martin Sjölund, 9 years ago

That is because the icons are still not loaded in the background. OMEdit does a ton of non-essential things before allow the user to access the GUI.

comment:6 by Martin Sjölund, 8 years ago

Milestone: 1.10.01.11.0

Ticket retargeted after milestone closed

comment:7 by Martin Sjölund, 8 years ago

Milestone: 1.11.01.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:8 by Francesco Casella, 7 years ago

Milestone: 1.12.0Future

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

Note: See TracTickets for help on using tickets.