Dynamics Code

I have compared the performance of Flow in Power Automate between non-current Flow and parallel Flow in Apply to each action in Episode 1.

We know turning Parallelism significantly improves the performance. However, the fundamental problem with the loop is that it is going through all 150 items. What if we can deduce the number of loops to iterate? Of course, you may make an argument there will some circumstance requiring to iterate all items. But, we are here to improve the performance of ordinary use cases.

Now, it is a question time.

“How can we cut down the number of loops?”

Bring a mathematical logic

We usually downplay the importance of mathematics in our daily programming life. Today, it may change a little bit of our impression.

I am sure you have heard and learnt intersection in Set theory. If you are a SQL guru, you would definitely know inner join. Let’s try to apply it here.

Instead of looping all 150 items and finding each of them in the given string, why don’t we create an array of the given string and intersect it with the array that contains 150 items? This will potentially cut down the number of iterations.

Let’s test it in C# program

Now, let’s go back to the C# program and implement the intersection mechanism to find the words.

The result keeps improving. Most of the time, the intersect mechanism outperforms the For loop by a small margin. A negligible difference you won’t notice in our daily life.

Let’s put it in the chart for a better visualisation. The difference is obvious.

Implementing Intersect in Flow of Power Automate

We gain about 90% performance when we turn on concurrency control and set its degree of parallelism to 20. What if we use the same arrays, split, and intersect functionality in Flow of Power Automate?

The result

I can’t tell you how long it takes to run as it’s faster than the minimise that can be recorded in Flow. Check the below screenshot.

It’s mind-blowing. 0 second. Can we say it is almost 100% performance gain? (Caveat: It may take several milliseconds to launch. The result depends on the number of items in the intersection array too.)

The takeaway?

These types of mistakes are common among pro developers. We can easily mask code inefficiencies given today’s computing power. However, when we try to convert them directly into SaaS/PaaS products like Power Automate and Logic Apps, we may end up creating an inefficient application.

We may not need to apply the most efficient algorithms all the time in a C# program, but, don’t forget a simple change in an algorithm can make a big difference in Power Automate.

Developers may have been writing inefficient code all this time. We may be simply trying to replicate the same logic of the classic programming in Power Automate, where our wrongdoings can get exposed.

So, pro devs, it is time to take a step back and re-align all our thinkings.

In the next episode

I will cover caveats of turning parallelism on in Apply to each action. Stay tuned.