Merge pull request #16410 from ronawho/no-loops-fast-on
Don’t consider loops as safe for the fast-on optimization
Previously, loops would not inhibit fast-ons, but loops can have an
arbitrary trip count, so it’s not something we really want to run in the
active-message handler. Technically there’s nothing blocking about a
loop that makes it illegal for the AM handler it can just be slow, which
can have serious performance implications.
This was causing large regressions for some Arkouda aggregation work
that optimized some of the flushing such that there was nothing else but
a large loop in an on-stmt. Making that loop run directly in the AM
handler had a large performance hit.