Parent loop conditions surprisingly don't seem to be faster.

Thing is, that even if they're not really faster, you should still do it for purely organizational reasons, so e.g. if you make a typo in the loop name and decide to fix it later (or decide to rename it for any other reason) you don't have to change several events that are part of the loop, just one.

I've found similar things, but not with loops, but with regular conditions (eg. Compare alterable value). I expected merging similar events into a parent loop would speed things up by eliminating redundant checks, but it didn't. IIRC, Yves said that using child loops was faster only if the child conditions referenced different objects than the parent conditions.

Might because the cost of child events counteract the cost of string comparison. Even the tradition compare method is O(n), the best case is O(1), just compare the length, as fusion just need to check if loop name equals, not need to find the first occurrence of a pattern.
Also, as for immediate events, all of these type are checked during one call. That is to say, all on loop are checked, all of their names are checked, and the iterate also cost time. Don’t know if fusion has some optimization for static loop names internally but this is the case of extension.

I recall a mention that fast loop names are actually optimised out if they are static (i.e. the fast loop's name is just one string, not an expression), so internally there is no string comparisons happening for those loops.

You can test this theory out by using "On loop 'MyFastLoopName("Active")' which will force Fusion to make a string comparison for this loop event.

Yeah there was an optimization several years ago to make fast loops with static strings use a direct reference instead of a string comparison reference, so there's no string comparisons going on if you're calling a static named loop from a static named call.

Quote from BartekB

I recall a mention that fast loop names are actually optimised out if they are static (i.e. the fast loop's name is just one string, not an expression), so internally there is no string comparisons happening for those loops.

You can test this theory out by using "On loop 'MyFastLoopName("Active")' which will force Fusion to make a string comparison for this loop event.

Yeah can confirm that it's slower when done like that, so Fusion most likely does it's optimizations on static loop names
On my tests it was around 50% slower (even if the string remained unchanged)!

It also should be noted that the latency of calculated "on loop" conditions doesn't seem to affect calculated "start loop" actions. It's only the "on loop" name that needs to be static.