| Tweet |
Introduction
One of the many new flow features introduced in Spring 22 is the Collection Filter - this processes a collection applying filter conditions and creates a new collection containing only those elements that match the filter, similar to a reducer from JavaScript. This seemed like something that would save a considerable amount of effort compared to manually iterating the collection myself and applying a decision to each element. But how much effort I wondered? As Peter Drucker may have famously said, "If you can't measure it, you can't manage it", or in this case, if you can't measure it you don't know whether it is any better.
Working with Salesforce at Enterprise scale often turns into a battle of Man V CPU, so I decided to measure the impact of switching to this approach in flow, and how carrying out the same processing in Apex performed.
The Challenge
The scenario was very (unrealistically) simple - query the Id and Forecast Category field for all opportunities from the database, create a new collection with just those in the Best Case forecast category. I used a random number generator to pick the stage for each opportunity created, and each of manual iteration, Collection Filter and Apex ran on the same set of opportunities.
Each method of processing was run three times in no particular order to try to mitigate the impact of caching, but as usual with this kind of testing, your mileage may vary enormously depending on what else is going on.
The Results
The results were as follows:
| Opportunity Count | Manual Iteration | Collection Filter | Apex |
|---|---|---|---|
| 500 | 480 | 90 | 20 |
| 1000 | N/A | 90 | 20 |
| 2000 | N/A | 116 | 36 |
| 3000 | N/A | 279 | 44 |
| 4000 | N/A | 397 | 65 |
| 5000 | N/A | 500 | 80 |
| 10000 | N/A | 850 | 151 |
One clear benefit of using the Collection Filter is the manual iteration tops out somewhere between 500 and 1000 records, breaching the number of executed elements of 2000, whereas the Collection Filter keeps going to the 10000 record limit that I imposed.
The filter approach is also about 5x more efficient in terms of CPU usage, although Apex is in turn 5x as efficient as the filter, but in all honesty if you are trying to wring every last millisecond of CPU out of a transaction involving thousands of records, flow won't be your first choice tool.
It's also good to see that the filter approach scales fairly linearly - somewhere between 80-100 msec per 1000 records, versus the 15-20 msec per 1000 records for Apex.
No comments:
Post a Comment