question

Iago MF avatar image
0 Likes"
Iago MF asked Iago MF commented

Custom Code Algorithm VS PF Algorithm Processing Time

Hi,

I developed an algorithm using a custom code in process flow. Then, I expanded the same algorithm using several process flow activities and I compared processing times using performance profiler for both.

The conclusion was that when I used expanded algorithm the processing time was shorter than the case were i was using a single custom code.

¿Can anyone explain me why this is happening?

Thanks in advance.

Custom Code algorithm:

1645447293349.png


Expanded algorithm:

1645446574444.png


FlexSim 21.2.3
processing time
1645446574444.png (96.0 KiB)
1645447293349.png (297.0 KiB)
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Jordan Johnson avatar image
2 Likes"
Jordan Johnson answered Iago MF commented

It's nearly impossible to answer without a model. But here are my thoughts on what you have provided.

My biggest concern is in comparing two different models. When converting activities to code (or vice-versa), it can actually be difficult to perform the exact same steps. For example, I see many Assign Labels activities. Often, when converting to code, people will not assign values to labels, and instead just use local variables. Usually, that means a speed improvement. But sometimes, using labels forces you to cache certain values earlier, and then look them up, where the code version may do a search every time. In that case, your code version would be a little slower.

So here's how I see it. If you convert from many activities to a single code block, you may see a little improvement. Usually, it's not worth your time; Process Flow adds very little overhead. In most cases, it's the approach that is either fast or slow, whether a token is moving through activities, or whether the code is executing directly. For example, if you search through a table, or use a WHERE query on a list, that is slower than looking up table rows with an index, or pulling from a partition without a WHERE clause. The choices of algorithm and data structure will dictate 99% or more of your performance.

So I can't explain why your two models perform differently. That would require you to provide both models, and for someone on the forum to do a deep analysis, to find the difference in algorithm between the two approaches. It could come down to the way you used certain commands, or shifting one line of code out of a for loop, or using a label instead of a local variable. But hopefully, you can analyze your own code and find opportunities for a speed-up.

I see the word "Dijkstra" in your comment. We recently made our AStar module public, so you can view the code. You may find it interesting:
https://github.com/flexsim/AStar

(Note: the github website was down when I wrote this, so you'll have to wait for it to be back up)

· 1
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Iago MF avatar image Iago MF commented ·

Hi, Jordan.

After reading your answer, I think that is very likely that in this case the difference was cache those values earlier when using Assign Labels on PF.

I'll see the AStar module code. Right now, i'm using a modification of Dijkstra cause i needed to consider some aspects that Dijkstra couldn't. Sure that code can help me to find a better solution.

Thank you very much!

0 Likes 0 ·