Cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Performance Optimization

Gears Phenom Gears Phenom
Gears Phenom

Hi,

 

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 Smiley Very Happy

 

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:

  1. use row-index and GETROWNO with combined type+sequence information (FAST INDEX)
  2. use row-index and GETROWNO with combined type+sequence information (NORMAL INDEX)
  3. search through row-index with FIND-method (FAST INDEX)
  4. search through row-index with FIND-method (NORMAL INDEX)
  5. search type and sequence column individually with FIND-method
  6. use a FOR-LOOP to find the correct sequence and type

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:

 

20160614_Vergleich_DatenhandlingTabellen.png

 

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.:

  • in modes 5) and 6) there's no need to fill the row-index, because it is not used anyway --> those would even be faster!
  • in the case without using the minimum sequence#, I was still updating that information in the SequenceTable, which costs some performance --> however this should be an equal amount for all modes 3)..6)

Any thoughts on this comparison are very welcome Smiley Happy

___________________________________________________________
Alex Dilg, Consultant at SimPlan AG (www.SimPlan.de)
This post was good and/or helpful to you? Please provide some Kudos, thank you!

Re: Performance Optimization

Valued Contributor
Valued Contributor

Hello,

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]).

 

Regards,

 

 

BD

99 little bugs in the code,
99 little bugs in the code.
Take one down, patch it around.
127 little bugs in the code...

Re: Performance Optimization

Legend
Legend

Hi Guys,
I try to compare the time costs of basic functions in SimTalk.
(Models and results are atteched.)
Conform the results your expectations?


Regards,
Nadin

Re: Performance Optimization

Siemens Phenom Siemens Phenom
Siemens Phenom

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.

 

_________________________________________________________________
Did you like the answer? Then click the Thumbs Up button.
Did the answer solve your problem? Then accept the answer as solution.

Re: Performance Optimization

Builder
Builder

Hi Nadin!

 

Thanks for this hugely interesting analysis. A view minor remarks:

 

  1. Interestingly, you were using the sysdate command for storing the begin of your test but not the end. If you use it absolutely saving the value as a datetime  in your tables, you may compute the time difference between end of the method and begin most accurrate.

  2. You are storing the end of a method at reset. Maybe to call a dedicated method when the chosen testmethod has ended. You put a bias on your analysis by including any further unknown processes running in PlantSimulation internally worsening your results in time demand.
  3. You were stating that you are using a 64-bit processor and a 64-bit OS. It seems (according to the screenshot of PlantSimulation), you are using a 32-bit version of PlantSimulation with an older patchlevel yet. Due to the fact, that you just got 2GB of RAM installed in your system, it doesn't make so much difference. I got the experience, that a 64-bit PlantSimulation (with more than 4 GB of RAM installed on the system) improves the execution performance of large models hugely.

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.

 

Best regards,

Mak

Re: Performance Optimization

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

Ok,

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!

 


Gert Nomden
Senior Consultant | Tecnomatix Product Manager
cardsplmsolutions.com

Re: Performance Optimization

Siemens Phenom Siemens Phenom
Siemens Phenom

I've made a small test, it's synthetic, just to compare 3 factors:

  • integer / string index
  • normal / fast index
  • find / getRowNo method

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

Regards, Vladimir.

Re: Performance Optimization

Siemens Phenom Siemens Phenom
Siemens Phenom

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.

_________________________________________________________________
Did you like the answer? Then click the Thumbs Up button.
Did the answer solve your problem? Then accept the answer as solution.

Re: Performance Optimization

Siemens Phenom Siemens Phenom
Siemens Phenom

Thanks! You are right, I did not think about it. After modification, model gives expected result.

Regards, Vladimir.

Re: Performance Optimization

Builder
Builder

Dear all!

 

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.

 

Mak