Problems with running time

Hello everyone!

I discovered a major problem with the runtime of my model. I like to simulate roundabout 5000 hours and its taking me ages.

I identified the function "centerobject" to be on of the main problems. In the test-model I provided you can see, that it takes about 16 ms of calculating, at least with this model and with my computer. In my actual working-model it takes about 40 ms.

That is definitely to long. I use this function very often and it slow me down considerably. Imagine me calling this function for every 2 seconds of the simulation time, then for every hour simulation, I need 28 seconds in real life. Now imagine doing 5000 hours repeatedly and with more stuff between it.

The logic of the model lies in the second conveyor in the Photoeye -> OnCover Function, open the Output console and you can see the time stamps, when an action occurs.

Can I do anything to make my model faster, or is it a programming problem, thats inherent to me building my model?

Btw, it also seems, that the time the function needs is depending on its position in the tree. When there are many object between the two refrencing ones, then it is faster. Actually, this didn't work out in my model.

Thanks for your answers,

Best regards,

Jan

System: Flexsim 4.38
PC: AMD Athlon XP 3000+, 2.17 Ghz, 1 GB Ram

Hi,

Do you have Visual Studio 2005/2006 or Visual C++ 2008 Express installed one your computer?
If you have try to do all the code to C++ and compile the model, this will
speed up everything. I did that on a model that have a run time around 30 minutes
after compiling I was down to around 10 minutes.
Visual C++ 2008 Express is free and can be downloaded from Microsoft.

Try also use a Recycling Strategy, Recycle to Textured Color Box in Sink.

What are you trying to do? It maybe exist some other way to do it.

Lars-Olof

Hello!

Thanks for the answer! I will try recycling the items on the next experiment.

I also use Visual C++ Express 2008 and have turned off all unnecessary statistics, but it is still slow. For example I need about 9 seconds for 1 hour of simulation time. That sounds quite good, but if one wants to simulate 5000 hours, that would make 12,5 hours of real time.

My model is about the front area of a miniload warehouse. It is done with a detailed strategy of how to transport which object, mainly using conveyor and merge sort. It has lots of deciscion like the one in the demo model.
Actually I can't do anymore about my programming right now. It will come down to cutting back the simulation time, unless anyone has a quick answer to work around that.

I also suggest, that the runtime of the standard functions of Flexsim is made clear in the documentation. Similar to the documentation of the functions for Visual C++ for example. If one knows, that "centerobject" takes more time than "getlabelnum" one might find a solution, that works around this problems form the start.

Jan

Hi,

One more idea, try to use node with rank, example node(3,model());
You can also try to use a Global Variable pointing to the object and using
the Global Variable in your first() call.

Lars-Olof

Lars-Olof, don't you mean node("/3",model()); ? The first parameter needs to be a string. Even faster than that would be rank(model(),3); because it doesn't need to parse the string during runtime.

Everybody, for more ideas on how to increase run speed, look here http://www.flexsim.com/community/for...read.php?t=460

Jan,

Please execute the following code in the script window on your computer and post the results. Your time trial is executing far more than the centerobject() command. I like your idea of making the execution times of the core commands visible in the documentation.


treenode object = NULL;
treenode conveyor = node("/Conveyor1",model()); //pick an object that has a center port 1 connection
double starttime = realtime(1)+realtime(2)/1000;
int numexecutions = 9000000;

for(int index=1; index<=numexecutions; index++)
{

object = centerobject(conveyor,1);
//pt(getname(object));pr();

}

double totaltime = realtime(1)+realtime(2)/1000-starttime;

pd(numexecutions);pt(" executions took ");pf(totaltime);pt(" seconds");pr();
pt("Average time per execution = ");pf(totaltime/numexecutions);pt(" seconds");pr();
pr();


The result on my machine is:
9000000 executions took 60.306000 seconds
Average time per execution = 0.000007 seconds

Meaning 0.007ms per execution and that includes the test expression in the for loop. Note that if you set numexecutions to 1, you will get 0.000000 time.

I dare anyone to remove the // in front of pt(getname(object));pr(); in the loop.

I only had the patience for 1000000 excecutions:

1000000 executions took 247.196000 seconds
Average time per execution = 0.000247 seconds

Note what this tells us about pt() and pr().

Kris

Jan,

When you reference an object through the center port there is a lot going on. If you were to write the code behind that function it would look something like this:

treenode cobj = ownerobject(tonode(getnodenum(rank(connectionscent er(current), 3))));
SAME AS
treenode cobj = centerobject(current, 3);

As you can see there are many functions that must be called and each one has more code behind it. If you were really concerned that this is where you were losing all of your time then you may want to look into using global treenode varibles.

Without seeing your model I would have to say that it may be more likely that something like recycling flow items as Lars suggested will be where you will save the most time.

If you are willing to post your model then I'm sure that the group would be able to give you better and quicker help.

Brandon

Originally Posted by Alex Christensen

Lars-Olof, don't you mean node("/3",model()); ? The first parameter needs to be a string. Even faster than that would be rank(model(),3); because it doesn't need to parse the string during runtime.

Everybody, for more ideas on how to increase run speed, look here http://www.flexsim.com/community/for...read.php?t=460

You are right Alex. I wrote the answer just right before I left work.
It should be rank.

Lars-Olof

Kris,

Your idea is very good one! I don't know why I never thought of writing a "for" loop in a script window to conduct execution speed tests. Wouldn't it be neat to have a table as Jan suggested with all the common commands and their relative speeds for a baseline of 9 million iterations like you did? In some cases, it may not be the best test, but it would be a start. There's a lot of ideas floating around about what's more efficient than something else, but as far as I know, it has never been documented quantitatively. I would love to know the relative speeds of senddelayedmessage, nodefunction, executefsnode, gettablenum (with all its overloads for tables references), etc. etc. If I had the time right now, I'd do it myself, but...

btw, here's my results for your test (looks like my computer is faster than your computer na, na, na, na, na, naaaa )

9000000 executions took 42.094000 seconds
Average time per execution = 0.000005 seconds

Cliff

Kris,

Result from my home computer.

9000000 executions took 45.406000 seconds
Average time per execution = 0.000005 seconds

Lars-Olof

Alright Cliff, if that's how it's going to be... I'll have to admit that the last runs were done on my 3.5yr old Dell Lattitude D800 that I still use for communication. I do most of my real work on a newer laptop Dell Vostro 1500 Intel T7500, 2.2GHz, 3GB RAM.

9000000 executions took 37.219000 seconds
Average time per execution = 0.000004 seconds

I'm sure someone with a desktop will demolish us though.

I should also admit that I have spent a couple of days doing tests like this and have collected some results in an xls but the organization is poor. Yes, I think there was at least one myth that was busted. I was thinking about making a presentation for the advanced class during the Flexsimposium this year, but it looks like I just gave away my secret tool. Note that it gets tricky for true comparisons because your CPU heats-up over time. I was alternating between 2 script windows (command sequence A vs command sequence B) and then taking the average of multiple tests. In other words: A,B,A,B,A,B,A,B,A,B is better than A,A,A,A,A,B,B,B,B,B because the B tests in the second case could be subject to a higher temp than A.

I'll see if I can get around to cleaning my speed testing xls before then.

Kris

Hi, the result from my computer:

9000000 executions took 38.656000 seconds
Average time per execution = 0.000004 seconds

Its a Dell Latitude D820, T7600 @ 2.33GHz, 2 GB Ram

Tobias

Flexscript:
Toshiba T2300 1.66Ghz:

9000000 executions took 55.656000 seconds
Average time per execution = 0.000006 seconds

HP E6600 2.4Ghz:

9000000 executions took 37.594000 seconds
Average time per execution = 0.000006 seconds

Compiled:
HP E6600 2.4Ghz:

9000000 executions took 2.281000 seconds
Average time per execution = 0.000000 seconds

That's more difference than I'd expected.

Flexscript:

Mobile Desktop Clevo 910 (3 years old) with P3 3.60GHz 2 GB RAM and Windows XP:
9000000 executions took 56.782000 seconds
Average time per execution = 0.000006 seconds

Compiled:
Mobile Desktop Clevo 910 (3 years old) with P3 3.60GHz 2 GB RAM and Windows XP:
9000000 executions took 3.000000 seconds
Average time per execution = 0.000000 seconds

I agree with Jason, much faster than expected.

Thanks Kris for the nice script and the idea how to check it.

As you guys have found out pretty clearly, flexscript is significantly slower than c++, especially when flexscript is the main code that's being executed (you wouldn't see as big a difference if flexscript is calling more cpu intensive commands that are implemented in c++, but since the script above is almost purely running flexscript code, it's a big difference). I'd like to revamp the flexscript runtime for a future release, i.e. 5.0/6.0ish, so that flexscript runs a lot faster, i.e. almost like java bytecode. One the big slowdowns (and memory hogs), is the whole tree structure that flexcript uses. Anyway, there are significant speed improvements to be made to flexscript.
As for Jan's original question, I think it's apparent that the slowdown is not attributed to the centerobject command. I'd advise looking at recycling, c++, etc. as the other users have pointed out.

easy -

just create a binding instead of centerobject(), or any other function for that matter.

bind on reset to a node variable, or better still a c++ pointer. flexsim support will show you how to do this.

it will be a hundred times faster.

eamonn

Hello everyone!

Thanks for all your answers, that is a very interesting thread.

Recycling the items saved some time. I also deleted all Visual Tools I did not need for the experiments. This cut the running time to approximately 2/3 of the original time.

Btw, the work is finished now, but I will definitely use your suggestions in further projects.

For comparison here are my results for the performance test:
Computer: AMD Athlon XP 3000 +
2,17 GHz, 1 GB RAM

Only for "centerobject":
9000000 executions took 53.314000 seconds
Average time per execution = 0.000006 seconds

With "getname":
1000000 executions took 305.812000 seconds
Average time per execution = 0.000306 seconds

I also just recognized, that I was using the "getname"-function for every single item that entered the system. I will definitely avoid this one in the future.

Thanks a lot,

Jan

For those who may be interested: it isn't the getname() function that is slow. It is the pt() and pr() writing to the open output console that takes so long when you uncomment that line in Kris's code.


string object = NULL;
treenode conveyor = node("/Conveyor1",model()); //pick an object that has a center port 1 connection
double starttime = realtime(1)+realtime(2)/1000;
int numexecutions = 9000000;

for(int index=1; index<=numexecutions; index++)
{

object = getname(conveyor);
//pt(getname(object));pr();

}

double totaltime = realtime(1)+realtime(2)/1000-starttime;

pd(numexecutions);pt(" executions took ");pf(totaltime);pt(" seconds");pr();
pt("Average time per execution = ");pf(totaltime/numexecutions);pt(" seconds");pr();
pr();


If you run that, it shows that getname() is just barely slower than centerobject().


If you are using getname() in combination with node("/this/is/a/really/long/path",model()) , then referencing things by name in the path of a node() function is quite slow, especially if you have many objects in your model that it has to search through to find those names.

This xls includes results of some execution speed tests related to:

1. writing to file and flowitem recycling
2. data type comparisions
3. reading stored data
4. tree structures - data vs folder nodes

If you are involved in a data-intensive model, you will benefit from knowing the fastest way of doing what you need. I encourage others to add to it if they conduct a test that has not been done.

Again, the point is to compare the relative speeds of commands with similar function. The actual speeds results will vary from pc to pc and with cpu temperature, but I expect the results of relative performance of different commands to be similar to these tests.

I am also attaching the model I used for reading stored data tests. Careful, there are 9 Script windows open.

Kris

I was interested in doing further tests related to the time to retrieve data from a Flexsim Global Table. Here's my results:

Reading From Row 2, Column 1 of a Global Table

Test ID  Description                                       Avg Runtime  Percent
1        getnodenum(rank(rank(LocalVariablePointer,2),1))  5.496        0.0%
2        gettablenum(LocalVariablePointer,2,1)             6.147        11.9%
3        gettablenum(GlobalVariablePointer,2,1)            6.170        12.3%
4        gettablenum(GLOBALMACRORANK,2,1)                  6.149        11.9%
5        gettablenum(GlobalVariableRank,2,1)               6.859        24.8%
6        gettablenum("GlobalTable",2,1)                    7.368        34.1%

Cliff