a user suggested to open a thread where we can discuss and suggest ways to improve the performance of a simulation run.
Please post all your suggestions in this thread.
I will start with a recommendation on accessing objects in methods.
Let's look at the following code:
is do local sum:real; for local i := 1 to SubFrame.TableFile.ydim loop sum := sum + SubFrame.TableFile[2,i]; next; print sum; end;
Here the path to the TableFile object has to be evaluated several times. This time can be shortened by assigning the TableFile to a local variable of type object:
is do local sum:real; local myTable := SubFrame.TableFile; for local i := 1 to myTable.ydim loop sum := sum + myTable[2,i]; next; print sum; end;
Now the path to SubFrame.TableFile has only to be evaluated once.
Some topics for animations: If you use a lot of lines/ tracks and many MUs on the lines/tracks, than you can increase the animation distance in the tab Curve:
In 3D: in V.11 right mouse click in the background of the 3D-Library window - Show graphics
You can go through your jt's, the objects are highlighted in green, delete all elements, you cannot see in the graphics and all elements you don't need, every element counts.
I had good results in accelerate models by transfer "flat" 2D-tables into nested-tables with indexes... (no searching anymore)
For big data-amounts I use SQLite as In-Memory-Database, also as data-backbone for warehouse and production controls.
At the end some simple rules (use the profiler): reduce the number of method-calls, reduce data handling (eg. use MUs as data-container instead read at each station the data from tables), reduce the running-time of methods (e.g. searching with find instead of for...loop, simplify the structure of the methods --> less lines), use a lean structure (user defined attributes instead global variables, less method calls in methods..), reduce the total number of moving objects (e.g. move empty container with the data about, instead of million parts)....
Some cases, I already found:
- some "old-school" programmer uses endless-loops for modeling a waiting-time...
- check the interval of generators (2 sec instead of 1 sec. means the half of method calls)
- method calls in methods (just by name), the methods cannot be finished until the last called method is finished...the simulation becomes slower and slower -->e.g. use methCall instead, avoid sub-calls
- console - writing in the console slows down the simulation - remove/ deactivate all print-commands from the final version of the method...
|Steffen Bangsow |
freelance simulation specialist
In principle you're right but I'd like to add that this might get counterproductive if you switch the graphic inheritance off that way. A good strategy to avoid such unwanted side-effects is to prepare the object classes before you use them (as far as that is possible).
Starting with v11TR1, there is also the "Optimize Graphics" feature that you can access using the context menu of a graphic. A dialog opens that offers you the possibility to optimize your graphics. To date, the dialog offers four optimization strategies with (depending on the specific strategy) several additional parameters.
In the bottom of the dialog, there are are four values that show you the complexity of your graphic so that you can compare the values before and after the optimizations you made.
The "setFormula" command seems to be a very powerful construct, if properly used.
My models lacked in performances, because I was using for loops to keep the data on the first level in a current state.
when using (for example for subtables):
... it helps a lot in keeping the overview over the current states much faster.
Of course the "calculateList" at the beginning of any method basing on the results should never be forgot.
When running the experiment manager some statistics may not be needed.
Turning off variable statistics.
Turning off the attribute "CollectData" from all charts in the model.
Customized statistics (in methods).
I usually add a boolean variable called "StatisticsActive" in the root frame programed to change all of these easily.
just did a short test in 10.1 and didn't get a crash.
Only the debugger opens as expected.
Attached is the model. Maybe I don't have exactly your case.
I resume this topic to ask about the find function for lists and tables.
If it is possible, I would like to know how it works internally; in order to understand the search cost of the function.
Furthermore, I wonder if the find function costs the same as getRowNo("name of index row"), without fast index access enabled and find that starts from cell [1,1].
Thank you for your help.