Multiple Choice - Series vs Parallel
Posted: 20 Aug 2017 13:14
Prolog
Many times in our flow, we have multiple choices, especially when using input dialog. We select one of the choice and the flow continues with the branch we choose. If the value of the choice is uniform and each branch do the same thing, there is not much problem of it. Since we only need to substitute the variable of {value} in the following action. Or probably pass it thru a map value before continuing to the next element. It is still a single logic flow, even though there are choices.
But what if each branch do something different? We can't use the same element to process the choice. Most of the time, we will do nested condition to check the {value}. So we tested it first if it matched the 1st choice, it continue with first branch. If not, then check it again with 2nd condition, if matched the second, continue with second. If not, check again with 3rd and so on. I called this style of checking : series.
I see the problem immediately, as each nested checking will take more additional time, adding delay to the whole flow when the choice selected is the last one. So I switch to parallel style of checking. From the input dialog, we branch as many condition as our choices and check them all simultaneously, but only one will be evaluated to true and continue with that branch.
I know it is faster, but I never tested it out how much faster than series. So here, this flow will tested it out. Multiple Choice - Series vs Parallel
This flow doesn't have real function. It is just to demonstrate the time delay difference for multiple condition connected in series vs parallel.
At first there is input dialog - Single Choice Menu, with choices from 0 - 9. Then you would choose between Parallel or Series. The script in each branch will noted down the time after the selection has been done and proceed to expression and finish with the script to calculate the difference between the time after finish, minus the starting time. Then output the time difference as toast message.
The left part is the parallel check, where from the starting script, it connects directly to 10 conditions expression and check them simultaneously. If it is true, then continue to the script dif. If false, do nothing (there is no false branch). Only one of the condition will result in true, the other 9 will always be false (and do nothing).
The right part is the series check, where from the starting script, it connects only to the first condition expression, evaluate it step by step throughout the whole choice. If true, the continue to the script dif. If false, continue to the next check. It will continue to check until the last condition, if the choice selected is the last.
Executing
You can execute the flow manually, try the choice, starting from 0. Choose parallel and try again with series. At my phone, 0 parallel give around 290-310, 0 series give around 280-300. It changes depends on the phone state. (My phone use SD617 (octacore) with 3 GB RAM.) But generally 0 parallel is slower about 10-14 miliseconds compared to 0 series. I tried this on my other phone, which use only SD415 2 GB RAM. It executes faster, only 90-120. Maybe because this phone is still fresh, is my secondary phone for testing purpose. Only install few apps.
Back to my main phone, moving to choice 1. 1 parallel still the same value, around 290-310 ms. But the 1 series now average at 400-450 ms. Why? Because it checked twice when selecting the second choice. (You can see the red color flowing through the second expression) There is additional 1 condition expression, which add around 130-140 ms (from my test).
Repeating the whole value from 0 - 9, parallel will tend to fall within 290-310 ms. While the series check delay keep increasing the moment we choose the higher value, with the average increment of 130-140 ms. So at the last choice : 9, parallel still around 290-310 ms, but series now average at 1450-1600 ms; a very huge difference! (5 times slower for 10 choices) Which means if we make the check in series style, the further (near the last choice) we choose, the higher the delay we experienced.
Parallel probably add additional 10-14 ms delay no matter how many choice we have. But series add additional 130-140 ms for every additional choice! The difference probably not so obvious when we have only 3-4 series check (300 ms vs 700 ms, only 400 ms delay). But i would prefer to optimize my flow to give the best perfomance whenever it can, especially when the flow have Control UI script inside. So parallel checking still is the best style to use if we have this kind of multiple choice : different action for each branch and only single choice allowed.
Conclusion
I am not saying that every elements in every flow must be done parallelly. That will cause a lot of logic problem in your flow later. In fact, most of the time it must be in series. Only for multiple choices situation like the one presented here, where only one can be true; then we are going to use this parallel style.
Many times in our flow, we have multiple choices, especially when using input dialog. We select one of the choice and the flow continues with the branch we choose. If the value of the choice is uniform and each branch do the same thing, there is not much problem of it. Since we only need to substitute the variable of {value} in the following action. Or probably pass it thru a map value before continuing to the next element. It is still a single logic flow, even though there are choices.
But what if each branch do something different? We can't use the same element to process the choice. Most of the time, we will do nested condition to check the {value}. So we tested it first if it matched the 1st choice, it continue with first branch. If not, then check it again with 2nd condition, if matched the second, continue with second. If not, check again with 3rd and so on. I called this style of checking : series.
- 1. Series.png (66.57 KiB) Viewed 11233 times
- 2. Parallel.png (49.07 KiB) Viewed 11233 times
This flow doesn't have real function. It is just to demonstrate the time delay difference for multiple condition connected in series vs parallel.
- 3. Multiple Choice.png (111.62 KiB) Viewed 11233 times
The left part is the parallel check, where from the starting script, it connects directly to 10 conditions expression and check them simultaneously. If it is true, then continue to the script dif. If false, do nothing (there is no false branch). Only one of the condition will result in true, the other 9 will always be false (and do nothing).
The right part is the series check, where from the starting script, it connects only to the first condition expression, evaluate it step by step throughout the whole choice. If true, the continue to the script dif. If false, continue to the next check. It will continue to check until the last condition, if the choice selected is the last.
Executing
You can execute the flow manually, try the choice, starting from 0. Choose parallel and try again with series. At my phone, 0 parallel give around 290-310, 0 series give around 280-300. It changes depends on the phone state. (My phone use SD617 (octacore) with 3 GB RAM.) But generally 0 parallel is slower about 10-14 miliseconds compared to 0 series. I tried this on my other phone, which use only SD415 2 GB RAM. It executes faster, only 90-120. Maybe because this phone is still fresh, is my secondary phone for testing purpose. Only install few apps.
Back to my main phone, moving to choice 1. 1 parallel still the same value, around 290-310 ms. But the 1 series now average at 400-450 ms. Why? Because it checked twice when selecting the second choice. (You can see the red color flowing through the second expression) There is additional 1 condition expression, which add around 130-140 ms (from my test).
Repeating the whole value from 0 - 9, parallel will tend to fall within 290-310 ms. While the series check delay keep increasing the moment we choose the higher value, with the average increment of 130-140 ms. So at the last choice : 9, parallel still around 290-310 ms, but series now average at 1450-1600 ms; a very huge difference! (5 times slower for 10 choices) Which means if we make the check in series style, the further (near the last choice) we choose, the higher the delay we experienced.
Parallel probably add additional 10-14 ms delay no matter how many choice we have. But series add additional 130-140 ms for every additional choice! The difference probably not so obvious when we have only 3-4 series check (300 ms vs 700 ms, only 400 ms delay). But i would prefer to optimize my flow to give the best perfomance whenever it can, especially when the flow have Control UI script inside. So parallel checking still is the best style to use if we have this kind of multiple choice : different action for each branch and only single choice allowed.
Conclusion
I am not saying that every elements in every flow must be done parallelly. That will cause a lot of logic problem in your flow later. In fact, most of the time it must be in series. Only for multiple choices situation like the one presented here, where only one can be true; then we are going to use this parallel style.