Increasing Run Speed

Running a large model or running a model for a long time can take a long time. Once you are running the model as fast as your processor can handle, setting the run speed to a higher value won’t speed up your model. When you want to get accurate data out of a model and don’t really care about visualizing or editing the model, there are several things you can do to make it run much faster.

Here are a few tips for making models run faster. If anyone has any other efficiency techniques, let’s hear them!

1)If you have code, such as a trigger, that is executed repeatedly but you don’t need to edit very often, make it a C++ node by selecting C++ at the bottom of the Code Edit window.
2)If you are done editing your model and you just want it to run fast, go to Build|Make All Code C++ in the main menus. Again, you will have to compile every time you change something in a Code Edit window, but it will run faster.
3)If you’re setting and getting labels often, reference labels by index instead of by name. For example, if “creationtime” is the first label of every flowitem, use setlabelnum(item,1,time()); instead of setlabelnum(item,”creationtime”,time());
4)Table usage can usually be optimized, too. Keep a pointer to a table, and use it to access the table instead of the table’s name or rank.
5)When you are running the model, close (don’t just minimize) all Orthographic and Perspective views. This way the drawing code won’t get executed to slow down the running of your model.

Some of these make the code less readable and harder to edit, so don’t do these optimizations until you have a model you are not going to change much. It is probably a good idea to keep a document with a list of these optimizations in case you do need to change something.

An alternative to using C++ code in the model is to put the C++ code in a DLL and then call the DLL from within the model. This is a much more complicated process but you end up with a model that you don't have to compile.

Thank you for the tips, Alex!

A.J and Anthony also advise me to try "recycling flowitem" (that I couldn't get it quite yet though )

Just want to share a little more tips that I learned from A.J. and Anthony for
(3) For the index of labels, define Global Macro index for the labels for each object and use them in more descriptive way.
(5) Also, they advise me to close not only the orthographic and perspective view window, but also output view (avoiding print any text) and trree view window. (Basically, all windows as much as possible I guess.)

Thanks,
Sung

I discussed this issue with Cliff in the past and these are a few points that we came up with to speed up a model

Q. How do you make a model run faster?
A. Reduce the number of executions that the computer has to do!

The tricky part is knowing the number of executions behind all the activities taking place a model.

First, I want to make a couple points regarding graphic display time. Every object in your model has draw events that only occur when one or more of the graphical windows are opened (i.e. Ortho, Perspective windows). These draw events are used to show and animate the objects, and they are executed every time the graphical view windows are refreshed (~30/sec). For instance the change in location of flowitems along a conveyor, the change in location of transports along a path, the simple display of a 3D shape of a processor, and the geometrical display of the bays and levels of a rack are all defined in these draw events. While a good computer graphics card helps ensure the smooth display, animation and navigation of the 3D views, it does nothing for your model execution time because none of these draw events are even executed when the view windows are closed. If you want your model to run faster, simply close your graphical views.

Points to remember (in no particular order):

1. Creating a flowitem is slower than moving a flowitem, therefore do not destroy flowitems, but simply move them to a temporary queue for later use. We call this recycling flowitems, and it will be a standard feature of the Source and Sink in the next release, but for now you can do it yourself.

2. Point 1 applys to standard nodes as well. If you are creating your own nodes for some dynamic data storage requirements or whatever, try to recycle the nodes rather than destroy and recreate them.

3. Reduce the number of events in your model. Try not to use "message loops", Watch Lists, or the listening feature of Flexsim to perform passive logic checks. Instead try to find a way to actively do the checks at only those times in the model when something changes that would require another check.

4. Avoid sorting the rank of flowitems in a large queue.

5. Avoid creating too many pending events (i.e. senddelayedmessage) at one time. If the outstanding event queue is large when a new event is created it takes more time to figure out where in the queue the new event needs to be placed, and then reorder the events accordingly.

6. A queue being used as temporary storage of flowitems should have its display of contents turned off, and the item placement set to "Do Nothing".

7. Referencing global tables, labels and other objects should always be done using pointers instead of referencing by name. In the case of labels, an index is faster than name referencing, but a pointer is the fastest.

8. Use numeric labels rather than string labels.

9. Always choose numeric comparisons over string comparisons in conditional statements.

10. Always use direct row referencing in table lookups rather than search & find algorithms.

11. Design models that have storage requirements such that inventory is updated and monitored via tables rather than using actual flowitems to represent the inventory. For instance a rack's inventory can be represented with numbers in a label table rather than with flowitems. When a flowitem enters the rack, simply update numbers in a table and move the flowitem over to a temporary queue to be recycled back into the model. (There will be some nice commands in the next release to make this easier for you - there will also be some nice commands to draw the rack's inventory based on numbers in a table).

12. Rather than redefine pointers in every function, set up a global function once for multiple uses.

13. Avoid the use of the node() command.

14. Rather than execute a nodefunction or sendmessage to execute code elsewhere, write the code to be executed directly.

15. C++ is faster than flexscript, and pre-built flexscript is faster than non pre-built flexscript. In otherwords, nodefunction() is going to be faster than executefsnode().

16. In a function, create local pointers when you find that you need to reference the same node/object more than once.

17. When reading via ODBC, read one entire row (record) at a time before changing rows.

18. Dynamically read/writing via ODBC, DDE, or OLE is going to be slower than communicating directly with a Flexsim global table.

19. When developing your own objects (i.e via the BasicTE and BasicFR), define all your animated motion using the OnUpdateOffset and Custom Draw Code fields rather than with message loops in the OnMessage field. The OnUpdateOffset and Custom Draw Code will not be evaluated when the graphical views are closed; making your model run faster.

I hope this helps

Dustin