That is exactly why I actually asked the question. I mean, MU's are being handled while they are "invisible" somehow, the question is how much it affects the performance. This was therefore quite an interesting experiment
I have attached the model, it was made in v.12. Two similar windows in the model will open, one solves the logic with additional MUs and the other with methods. In the frame "Robotcell" there is an assemblystation. The logic in mind is how the assemblystation recieves components according to the individual BOM for each product arriving in the assemblystation. Hopefully my SimTalk documentation makes sense if anyone decides to look into it in detail.
The big difference is actually in the init-methods. The method-way of doing it have much more initializations to do before it starts, but it only does this in the beginning (not everything is necessary, but I have developed the method-way to be more flexible). The MU-way does a lot of work for every product that arrives at the assemblystation, which is probably why it takes more off the performance.
I added my model in the post above, it shows the information the MU's carries. But basically it is only a BOM that is moved in several steps. My basic questioning is how much MU's affect the performance when they are not animated, which I see is a hard question to answer. My experiment in my model shows that MU's do affect the performance quite significally.
I am not a simulation engine developer, but you must imagine the internal processes linked to the creation / destruction of every MU as an object derived from a class. It is generally recommended to use a minimum of moving units.
PlantSimulation has like any other object-oriented environment the feature to use constructoirs and destructores, which means that certain routines are triggered every time a MU is created. If you click on the MU with the right mouse button and open the Attributes and Methods, you can see how mich memory(space) a certain element is using in your model.
A table is (normally) much easier to create internally and also more dedicated to the purpose. I sometimes prefer in-memory tables, which are built during runtime of the model inside of a method instead of establishing additional objects.
In any case, an in-memory database basing on sqlite makes things much easier when managing large amounts of data. At the moment, one of my tables has the information "MemUsage: -1145080127" (whatever unit is assumed - even the helpfile is hiding this information). This is an old legacy and deleting that table for re-initialisation takes more than 340 seconds (according to the profiler).