first it's so great that I can use "//" as comment in 2.0...please implement some notepad ++ functions in next time ;-) for example highlight of the same variable by select in method...
@Skeeve I have your model a little modified. If my result is correct (please confirm!!!), I find interesting the effect (index exists or does not exist) on the performance. For the setting "fast" and "getRowNo" almost no time difference between index exists found and not found.
@MichaelJoos include the result
Wrong Index 0.0940 seconds
the time to determine that the index is wrong? So it exist a offset for all find-searches to determine that the index is wrong.
time to change fastAccessRowIndex in TableString1 --> normal, : 0.0000 seconds
TableString1 --> normal, find, Exist 1.1090 seconds
TableString1 --> normal, getRowNo, Exist 0.3910 seconds
TableString1 --> normal, find, not Exist 2.8130 seconds
TableString1 --> normal, getRowNo, not Exist 1.0000 seconds
TableString1 --> normal, find, Wrong Index 0.0940 seconds
time to change fastAccessRowIndex in TableString1 --> fast, : 0.0000 seconds
TableString1 --> fast, find, Exist 1.1250 seconds
TableString1 --> fast, getRowNo, Exist 0.0620 seconds
TableString1 --> fast, find, not Exist 2.8130 seconds
TableString1 --> fast, getRowNo, not Exist 0.0620 seconds
TableString1 --> fast, find, Wrong Index 0.0940 seconds
time to change fastAccessRowIndex in TableInteger --> normal, : 0.0000 seconds
TableInteger --> normal, find, Exist 0.8130 seconds
TableInteger --> normal, getRowNo, Exist 0.1560 seconds
TableInteger --> normal, find, not Exist 2.0780 seconds
TableInteger --> normal, getRowNo, not Exist 0.3280 seconds
TableInteger --> normal, find, Wrong Index 0.0940 seconds
time to change fastAccessRowIndex in TableInteger --> fast, : 0.0150 seconds
TableInteger --> fast, find, Exist 0.8130 seconds
TableInteger --> fast, getRowNo, Exist 0.0470 seconds
TableInteger --> fast, find, not Exist 2.1090 seconds
TableInteger --> fast, getRowNo, not Exist 0.0470 seconds
TableInteger --> fast, find, Wrong Index 0.0940 seconds
I hear a lot of critisism from you lately.
Please believe us that we at Siemens really try to make the software user-friendly, and we try to give you a helpful online help. Some people really like the documentation, some complain about it. I guess it depends on the fact whether you found an answer to your question or not. Please understand that it is very difficult to answer all possible questions. Also we do not want to cram the online help with obscure stuff, because it would make it even harder to find the really important information.
That is one of the reasons why this forum exists, and why we invest some of our time in answering your questions. Thank you to everyone contributing to this forum and answering questions.
About the performance topic: Some of the best practices are obvious. Some are not so much. Still, if you are not sure which approach is faster, you can always try it out. If you have a Professional License, you even have a profiler at your hand, with which you can find the critical Methods that are worth being optimized.
Let's distinguish between the efforts making the software user-friendly to sell additional licenses and to support professional users in pushing the limits with PlantSimulation.
With respect to the first point, of course Siemens is investing a lot. Concerning the second point, I am currently missing appropriate similar efforts. Instead I got the impression, that just the main customers are focused on and less the smaller ones.
These two points mentioned at the beginning do not contradict. There are several examples, where quick-start guides for the beginners are assisting in getting in touch with the software, while for professionals a more detailed documentation on the necessary internals is available and can be used.I am missing the second type of documentation. It was never demanded to mix up everything in only one helpfile.
The profiler is nice and I am using it already for a long time. It just gives a hint where to look for additional performance. It doesn't give any glue on how to achieve a better performance in the most critical methods outlined. So I don't regard this hint as an appropriate answer eveen less solving the issue discussed in this track.
I thought this time I could be lazy and ask you first, whether anyone has compared the following 2 approaches for adding data to tables already
iRow := someTable.yDim + 1; someTable[1,iRow] := "Bla1"; someTable[2,iRow] := "Bla2"; someTable[3,iRow] := "Bla3";
iRow := someTable.yDim + 1; someTable.writeRow(1,iRow,"Bla1","Bla2","Bla3");
I'm always wondering and never found the time to check the performances myself, so...
writeRow is faster if you write to more than one table cell. The more cells you write to, the greater the benefit.
If you write to a single table cell, the brackets are faster.
I have a general question regarding MUs in models. I have a model which uses MUs as components to be assembled in an assemblystation. I also use MU's as signals to indicate from which buffers a PickAndPlace should take components from.
What this implies is that I use approximately twice as many MU's as necessary by using them as signals as well. I could use methods for this instead, but it is a bit more complicated. If I fastforward the eventcontroller, would it be benefical for the performance of the model by using methods instead? Since animation is skipped with fastforward, will it make any difference?
An update regarding this, I solved the logic with methods instead so I now use approximately half the amount of MU's in a model. I simulated both models for 30 days (with fastforward in eventcontroller) and made a comparison. Using methods was approximately 40% faster, which is a quite big difference.
I would have imagined so; turning off the animation still requires the MUs to be handled "invisibly" with all the memory-requirements. But good that your experiment backs up the assumption Though it would be interesting to see what exactly you did with your "flag-MUs" and how you replaced them with logic. Maybe it can help other users to also make more usage of logic/methods instead of MUs.
sorry for not answering earlier, I was hugely busy.
Basically I don't know, what kind of information you intended to transfer with when using MUs.If there is a large amount of different information (with different variable types), either using byref (if more than one result should be returned) or using a message inbound table might be two other options.