I've also always wondered about this question. I took the liberty of recycling the IMDB-example model by @Steffen_B from the PS WUC 2014, so props to Steffen again at this point
In this special example, it is easily saved in a table and therefore known, which sequence# is the next/minimum for a certain type (1,2,3). However, I also compared an approach where I assume to not know it and therefore the stock-table has to be searched to find the minimum sequence# for the required type.
If the min sequence# is known, I can use the row-index to store a combination of type+sequence#, which can then easily be searched (with getRowNo in modes 1) and 2), or with find in modes 3) and 4)). In mode 5) the regular columns (i.e. no row-index) are searched with the find-action, and in mode 6) I walk through the table with a for-loop to find the row with the minimum sequence# and the required type. Here's an overview:
In the case where the minimum sequence# is not known and has to be identified from the table, I now only save the type as a string in the row-index-column. Note that I can no longer use the getRowNo-action, because I don't know the sequence# I'm searching, and it would always give me the first row with the target type. In all cases, I search/walk through the whole table and store the current row# and current minimum sequence# in a local variable.
Here are the results for a 1000x50 warehouse and 10 days simulation time:
Naturally, it is way more efficient if I already know the minimum sequence# that I want to retrieve.
As you can see, getRowNo is faster than find, and the fastRowIndexAccess also speeds up the search, but of course only if the getRowNo-action is used! The find-action does not benefit from the fastRowIndexAccess!
What I also found interesting is: using the find-action on the row-index was slower than on the regular-columns, but that probably occurs because the row-index is a string-column and the others are integer-columns.
Walking through the table with a for-loop was much slower than iteratively jumping to the next row with find!
Note: it's not a perfectly fair comparison, because some data-handling (table-writing and string-conversion) would not be required in all cases, e.g.:
Any thoughts on this comparison are very welcome
that's a very interesting comparison. Thank you.
What is impressive is the huge difference between for-loop and find.
When I'll have a bit of time, I would like to test if the difference between the fastest methods and a search with an o(1) method is significant. With o(1) search I mean, for example, a way to store data in a table using the row number to know exactly what I'm looking for (e.g. storing MUs information using getNo as a row index, and when I need data: Table[col,@.getNo]).
Thank you for your detailed analysis.
Let me add a few comments.
The number of lines in a Method does not directly affect the runtime of the Method. Some instructions take more time than others. For example sorting a large table takes much more time than assigning a value to a local variable. Also, you need to count the number of executed instructions instead of the number of lines in the source code. If instructions are not executed (for example because the if-condition is not true) they do not affect the runtime. If instructions inside a loop are executed multiple times, they count multiple times.
There is one thing that I cannot confirm. An if-then-else instruction is not slower than inspect-when-else (or switch-case-else in SimTalk 2.0). I am not sure why you got this result. When I tried it then if-then-else was faster. Please note that i==0 is the check for "is about equal to zero" which is a tiny bit slower than "is exactly zero". You need to write i=0 if you want to have the same behavior as the inspect-statement. Note that the inspect-statement is in fact faster than if-then-elseif-elseif-...-else.
Thanks for this hugely interesting analysis. A view minor remarks:
If you are interested, there are dedicated simulation comparisons available, where various different simulation packages are compared to each other (see: http://www.argesim.org/index.php?id=68). Be aware that (except the last ones) only the even comparisons are discrete event. The odd ones are of continuous type.
I checked the link that looks interesting at first. Unfortunately the contents seem to be grossly outdated! At least, the Plant Simulation development team has made great progress, in terms of capabilities, user-friendliness and computational performance. Some examples on the site are >15 years old!
In the case descriptions on the site, I do not see how they can be used for software comparisons of any kind, it is all purely illustrative. So, I would welcome some updates of the contents!
I've made a small test, it's synthetic, just to compare 3 factors:
Here's a log:
Integer index, normal, find: 0.1900 seconds Integer index, normal, getRowNo: 0.5270 seconds String index, normal, find: 4.0940 seconds String index, normal, getRowNo: 1.5830 seconds Integer index, fast, find: 0.1670 seconds Integer index, fast, getRowNo: 0.1020 seconds String index, fast, find: 2.9120 seconds String index, fast, getRowNo: 0.1600 seconds
Basically, results are the same, but first case is interesting. It seems that "find" is faster when using integer index in normal mode.
I've attached a model in v.13.0.1
getRowNo is always faster than find. In your example find does not work.
There is a differerence between getRowNo and find: find always fails if the data type of the value you are looking for and the table data type do not match. You pass a value of data type real, but the table column is of data type integer. So find always immediately returns false.
getRowNo on the other hand converts the real value to integer by truncating in. Then it searches for that value.
Thanks to everybody participating in this discussion and providing valuable input.
All messages clearly illustrate the current lack of dedicated information especially on this important topic and necessarily demanded from the producer of the software. The hints given by Siemens part by part are showing that only Siemens is in possession of the internals of PlantSimulation and therefore the only one who can support its customers and developers appropriately.
Let's have a look how customer oriented Siemens is going to be.