Apply to each actions can take longer than the actions inside of them

[bobesponja]

Does this happen to anyone else?

I'll have an Apply to each (with concurrency enabled) that claims to have run for 4 seconds, but on the inside you can clearly see it only ran 5 iterations or less, and each action in those iterations had an estimate of 0-1 seconds. This happens to me frequently, even on highly optimized flows where the Apply to each section is doing as few actions as possible (none of which involve communicating with an outside source) and where it has less than 5 iterations to process. It wouldn't be so bad if it didn't make it harder to troubleshoot where flows go wrong, since sometimes I have to find the source of a slowdown, but the only thing that's slow is an Apply to each action with two built-in actions inside of it.

This also happens to me sometimes with general flow runtimes, where a flow run might be estimated at 8 seconds, but almost every action in that flow was timed at 0 seconds. This, again, would not be an issue normally, but it makes it harder to solve slowdowns.

EDIT: The flow run below is an example of the Apply to each issue, in the second set of concurrent action lines. Before the lines begin, the ItemsToProcess action filters out any items from FormattedSQL that are identical to an item in FormattedSP. Then, on the right branch, the Apply to each loop (concurrency 20) checks if the vehicle number for each item in ItemsToProcess is found in GetAllItems, and creates the body of a SharePoint POST (or PATCH, if an existing entry was found) request for that item. Meanwhile, the left branch filters for any FormattedSP items whose vehicle numbers aren't found in FormattedSQL, for which it generates DELETE requests in the same way that the right branch creates POST/PATCH requests (though this flow usually doesn't have anything to delete). After both branches complete, the ResultsToString action joins all of the requests bodies into a single block of text, which will go in the body of an HTTP batch request under the Condition at the end (the condition checks if there are any requests to submit, and does nothing if no requests were made). 

The Apply to each loop on the right branch shows that it ran for 7 seconds. However, each of the actions in all 6 of the loop's iterations claim to have taken 0 seconds to run. The GenerateDeletes loop apparently also took 1 second to run, despite having nothing to iterate over.

I checked another flow run after this, and it claimed that GenerateDeletes ran for 3 seconds processing nothing, and that the other Apply to each ran for 5 seconds processing 2 entries (both of which had 0 second runtimes for all actions). For the first flow run, one might argue that the Apply to each runtime makes sense since 7/(6*2) = 0.58 seconds (assuming they all take the same amount of time), which might get rounded up by Power Automate. But for the second run, you'd expect to see something, since 5/(2*2) = 1.25 seconds, meaning that at least one of these sub-actions should have a time greater than 0.

I'll have to look more to see if I have any examples of the full flow run timing not being equal to the seconds added up from each action, which I remembered seeing a while ago but I wouldn't have the run data anymore.

[eliotcole]

Hi, @bobesponja, is there a chance that you can show us the problematic flow? If so, please embed (adding images to the post, not attaching or linking them) some imagery into your original question above.

This will just help folks here resolve your issue for you more quickly.

---

Now, if I were to hazard a few guessy suggestions your way, hopefully these will assist you somewhat. If not in resolving it, at least maybe in fault finding whatever it is you're looking for.

Suggestion 1 - Delay

With regard to your current setup, if you wish to have a bit more visibility of how long things are taking you could run a delay action at the start of each loop, then prior to whatever action you're concerned with add a Current time action, then add another Current Time action directly after it.

At least there you can start to get some visibility of how long things are taking, you could even do some clever maths to work out how long, too. 👍

Suggestion 2 - Select / Filter

Would it at all be appropriate to the data that you are working with to push it through a Select or a Filter data action before you run whatever it is you need to run on it?

These can allow you to preconfigure a lot of things and often avoid loops entirely!

Suggestion 3 - Avoid Variables In The Loop

Whilst I am sure that you know what you are doing, I also know that I forget the most basic things quite often. This is one of those.

Sure, some variables will be OK if they are not being calculated in the loop, however any variables that are changing in the loop can (and often do) carry to concurrently running loops. This means the same data is being used where you would prefer it not to be.

In such situations, move to Compose actions to hold the data that you need to refer to, or calculate directly in a given action / expression.

[eliotcole · Accepted solution]

OK, now I have a bit more context, I can tell you this: Don't get too hung up about these run times ...

They are (at best) approximations on a theme.

---

Furthermore, looking at the actions that you have in those loops there, @bobesponja ... I am relatively willing to bet that I/We could figure out how to do them 'instantly' within a Select action or two. If there's just too much sensitive data in there, then you can DM me about this, but realistically it would be good to see what's going on in those Data actions in the Apply to each and GenerateDeletes loops that you have there.

For example, is it just a filter and a compose action in Apply to each? If so, it's likely not going to be helpful to anything as is.

[bobesponja]

Sorry for not responding yesterday, I was swamped.

I have considered changing the Apply to each to a Select action before, but I can't get the SharePoint ID of the entry I want to update without using the Filter action. This flow just makes sure a SharePoint version of an SQL table stays up to date (I know this is extra work, but I'm required to work in these limitations currently), but since the SQL table doesn't have the SharePoint ID number, I have to use Filter to find the item's SharePoint ID (if any) and Compose to create the HTTP response body based on that output. I have considered switching to an alternative flow that runs when an item is created or updated, which would avoid the Apply to each issue entirely, but that approach doesn't recover from failures as easily (because you'd be waiting for the next time someone edited that item instead of waiting for the next successful flow run).

This is what the insides look like. Pretty much everything could potentially be moved to a Select *except* for the Filter part.