It’s weird. I’ve tried recreating the scenario with other conditions and custom states checks and I’m not able to pinpoint when it happens. I just know that custom state checks it delays the operation. Doesn’t matter if the state is set or not.
Well, doesn’t it depend on what the condition being tested is? I use terminate steps in various (iterative) workflows to speed things up and they do speed things up in that context.
(Specific use case is doing complex lookups for nightly rates in a booking app. There are multiple types of rates, each with priority over some other rate. If a high priority rate is found, I stop looking further within that particular workflow to avoid performing needless conditional evaluations in later workflow steps. I found that terminating workflow rather than letting it continue resulted in performance improvement.)
Yeah, that seems weird and could possibly be a bug. (I’m all for fixing anything that seems like a performance hit, for sure.) I’d definitely take the time to file a bug report on that if you have a good example case for the support team.
(You probably know this, but they are actually extremely effective in getting stuff like this resolved in cases where the reported behavior is actually a bug.)
P.S., by liking your comment, I am simply acknowledging this very interesting info. I’m not “liking” the fact that that very simple condition seems to be taking a long time to pass! )
) to measure times.
)