Opened 8 years ago

Last modified 6 years ago

#3823 accepted defect

Store less information in ElementSource

Reported by: adrpo Owned by: adrpo
Priority: high Milestone: Future
Component: Frontend Version:
Keywords: Cc: sjoelund.se

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 Changed 8 years ago by adrpo

  • Cc sjoelund.se added
  • Owner changed from somebody to adrpo
  • Status changed from new to accepted

comment:2 Changed 8 years ago by sjoelund.se

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 Changed 8 years ago by sjoelund.se

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 Changed 8 years ago by anonymous

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 Changed 8 years ago by sjoelund.se

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 Changed 7 years ago by sjoelund.se

  • Milestone changed from 1.10.0 to 1.11.0

Ticket retargeted after milestone closed

comment:7 Changed 7 years ago by sjoelund.se

  • Milestone changed from 1.11.0 to 1.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:8 Changed 6 years ago by casella

  • Milestone changed from 1.12.0 to Future

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.