Performance – is Flow faster than PowerApps?

(ESTIMATION TIME: 4 MINUTES)

In this post I’ve showed you how you can create PowerApps app that utilize SharePoint Search for your business. I used there PowerApps for parsing big string containing our results from SharePoint Search.

But one o my readers asked me an interesting question

“Mike, wouldn’t it be easier and faster if we parse results in Flow and pass to PowerApps just raw field values?”

Jacek M.

Hm….at that time I didn’t know the correct answer. Neither I could find it in the PowerApps Canvas App Coding Standards and Guidelines . That’s why I’ve decided to make quick test on my own and publish its results on my blog.

Time measurement 1: parsing on PowerApps app side

It’s pretty straight forward to measure parsing time for the application we’ve built in my previous post. Just add timer control, start the timer before firing flow, fetch results from flow, parse it and stop the timer right after it. It will look like this:

I’ve setup my test to fetch 10 results. Result of it: 1 second! 1 second is the time that PowerApps need to fetch 10 results from flow and extracting required field values (Title in this case). But that was not enough to me. I thought: “let’s see how long will it takes to get 100 results and extract 4 fields”. The results surprised me. 1 second again!

It will be very hard to beat it but let’s give it a shot! Let’s check how Microsoft Flow will manage to extracting field values.

Time measurement 2: parsing on Flow side

Disclaimer: John Liu in this tweet proved I was wrong. My double loop in flow was quite a bad idea..both from conceptual and performance perspective. He’s built a flow which was 15x faster than mine! This means PowerApps is not 30x but “only” 2x faster than Flow…and that also I need to take some flow building lesson 😉

To cheer myself up I can only say:
those who do nothing makes no mistakes.

First let’s start from small test that is fetching 10 items and only Title field. The modification of the flow is simple: I will iterate through each row of the SP search results, then through each cell in a row (each row contains multiple cells) and then once I find the cell I’m looking for (Title in this case) I’ll append cell value to an array variable. Modified flow will look like this:

Parse Cell action allows for using Key, Value, ValueType attributes in farther actions. The Join action that is in the bottom of the screenshot is used to convert array to text value (because PowerApps does not accepts arrays 🙁 ).

For start I will just take 10 results and extract only Title field. Let’s test this configuration:

WHAT?! 32 seconds!? I must admit – I expected that Flow will be slower that PowerApps but not ~30 times (it’s obvious why it’s a common pattern to use your end user CPU time, via browser or mobile memory, rather than your own) . That’s huge difference and strong argument for using PowerApps for all kind of parsing and any CPU expensive calculations and not using Flow for that.

Further testing (more fields, more items) has no point. Let’s jump right to the conclutions.

Conclusions

Personally I find this small test really informative.

First: It’s more efficient to use PowerApps for calculations that Flow. It’s worth to tell it even if most of us know that common good practice is to distribute calculations and delegate it to user device.

Second: In the light of above note, consider making more than 1 call to Flow and back to make most of the expensive calculation on the PowerApps side for the sake of whole process time consumption. E.g.:

1. PowerApps asks Flow to get results from SPO Search
2. Flow get results and pass it back to the app
3. PowerApps extract some data (specific fields, values range, values sum etc) and pass it back to Flow
4. Flow gets additional data for selected items or fields and pass it back to PowerApps again
5. PowerApps display results to user

What do you think about that? Does this test was also informative for you? Or maybe I missed something that may change whole results – let me know!