Model execution time

Question

question

Lucas Klein asked Sep 17, '18 Jordan Johnson answered Sep 25, '18

Model execution time

Dear all, I have a few questions about model simulation time below:

1 - I am working in a model and I am using the FlexScript Code Profile to search for "heavy" logics that might be slowing down my model. My doubt is that if is there another tool that could help me to find out these logics and if FlexScript Code Profile works as well for ProcessFlow logics as for code analysis (like triggers, UserCommands, etc.)

2 - Does ProcessFlow executes the activities faster than coding them in FlexScript?

3 - About the ProcessFlow activities, is there any list or analysis comparing the activities according to time of execution or wich one impacts more the execution time of a model, since there is activities that requires some constant check (e.g. Wait for Event) and others that is just pontual code (e.g. Assign Label).

Thanks in advance.

Software Version:

FlexSim 18.0.7

process flow flexscript model speed

Answer 1 · 2018-09-25T19:11:52Z

Jordan Johnson answered Sep 25, '18

Things that can slow down a model significantly:

Using a delay to frequently check for some value to change. Use event listening or lists instead.
Queries in a Pull from List. If you frequently query a large list, that will be slow. Use partitions or multiple lists to avoid WHERE statements. Try to avoid ORDER BY statements wherever possible.
Back Order Queue Strategies on the List or the Zone. These are just queries. That query is run every time something exits the Zone, or is pulled from a list. The "table" being queried is a list of tokens, either on a the Pull from List activity, or an Enter Zone activity. If tokens frequently leave the zone, and there are lots of tokens trying to enter, this will be slow. With a list, if tokens are frequently pushed on the list, and there are many tokens trying to pull, it will be slow.
Searching a table frequently. For example, if 100k tokens all search for a certain row in a 50k row table, then you are reading the table up to 5 million times. Instead, use a list like a map; the partition can be some value, and the entry can be the row number.
Busy or nested for loops. If lots of tokens execute a loop lots of times, you end up multiplying the work. Try to avoid these.

Those are the biggest ones I see frequently.

To find slow things:

Read the list above, and look for those things
Run the model for a while, and look for the following:
1. Activities where tokens "pile up". Is there a query being run on those tokens? Is there a way to have the activities wait somewhere less expensive?
2. Activities with high input/output statistics. Check any loops of activities, and see how many times the activities are being executed. Are there simpler activities that could be used?

Answer 2 · 2018-09-20T15:07:19Z

Ben Wilson answered Sep 20, '18 Phil BoBo edited Sep 25, '18

Hi Lucas,

@phil.bobo and @jordan.johnson will be able to comment better on raw performance of FlexScript vs Process Flow

It is worth noting that in each case the execution speed will be greatly dependent on the modeler's implementation of the logic. There are certainly fast and slow approaches to accomplishing the same task, regardless of the tool.

It's possible that if you attach your model, our support team could suggest ways to improve your algorithms to be more efficient. But perhaps they are already very efficient and your problem is just a hard one to solve. Unfortunately without your model we can't offer anything more concrete.

Hopefully Phil or Jordan will provide an answer to your questions 1-3, which this answer avoids since I don't know that info, and I'm really just trying to grab their attention so they'll answer your questions. Good luck!

· 2

Lucas Klein commented · Sep 25, 2018 at 05:00 PM

Thanks @Ben Wilson, hope that @phil.bobo and @jordan.johnson could help me to understand further this difference between FlexScript vs Process Flow

Good to know that the speed of accomplish some task deppends more from the modeler than the tools, here we are always improving best practices to avoid deprecated or slow modelling techinques. This helps us to understand more about the operation of FlexSim and provides guidance to achieve better results on our projects.

0 ·

Phil BoBo ♦♦ Lucas Klein commented · Sep 25, 2018 at 05:25 PM

1. The FlexScript code profiler only works with FlexScript code, not ProcessFlow Activity code in the ProcessFlow.dll.

2. This is comparing apples to oranges. How do you code a ProcessFlow activity in FlexScript?

For some simple activities, such as the Assign Labels activity, then the ProcessFlow activity executes some code with regards to starting the activity, processing the activity, and finishing the activity, in addition to the code that actually sets the label. So in that regard, FlexScript is "faster" in that you can set labels directly in FlexScript functions. But if your logic is in ProcessFlow, what are you doing to do to execute that FlexScript function to set the labels? Use a Custom Code activity? That adds the same overhead. Even this simple case is comparing apples and oranges. The speed difference is in what is calling the code to set the labels (whether a ProcessFlow activity or some other method that is executing FlexScript), not the code or activity itself.
For most activities, such as Delay, Batch, Wait for Event, Acquire Resource, etc., there aren't equivalent FlexScript commands. You can't "code" that activity in FlexScript. What does that even mean?

3. No.

Also, the statement "there is activities that requires some constant check (e.g. Wait for Event)" is false. The Wait for Event doesn't constantly check. It doesn't use a polling mechanism. It adds a listener to that event so that when the event is executed, it fires a callback on the listener. It doesn't have to "constantly check"; it only checks when that event is executed. Once. Not constantly.

0 ·

question