PrimitiveAlgo : Optimize transformPrimitive

[danieldresser-ie]

Applies on top of #6026.

This optimizes 3 things: added threading, moving the check for interpretation out of the inner loop, and moving the canceller out of the inner loop. In theory, we only needed to delay the threading fix out of the previous PR, but the other two require splitting into subranges anyway, so it's easiest to keep them together.

[danieldresser-ie]

Oh, and some performance numbers: this is embarrassingly parallel, there's an 8X speedup in the test turning on threading. The other two fixes are minor, around 10% each after threading.

[danieldresser-ie]

@johnhaddon I wasn't sure what would go wrong if I just tried to switch FreezeTransform to inherit from ObjectProcessor, so I just tried it. Everything went pretty smoothly ... except that it doesn't actually work because FreezeTransform needs to process any objects that have ancestor matches, whereas ObjectProcessor is hardcoded to affect only objects with exact matches.

Do you think it could be reasonable to allow customizing that on ObjectProcessor? Or perhaps I could just make an intermediate filter plug on FreezeTransform that returns ExactMatch whenever there's an AncestorMatch?

[johnhaddon]

except that it doesn't actually work because FreezeTransform needs to process any objects that have ancestor matches

Ah, of course. Sorry, I should have anticipated that.

Do you think it could be reasonable to allow customizing that on ObjectProcessor?

What would that look like? Some sort filterMask = PathMatcher::ExactMatch constructor argument that we'd pass ExactMatch | AncestorMatch to?

Or perhaps I could just make an intermediate filter plug on FreezeTransform that returns ExactMatch whenever there's an AncestorMatch?

I'm not sure that can be made to work without modifying ObjectProcessor, since it would need to know to look at the intermediate filter and not the main one (and we can't connect something to the main one, because that is user-facing).

Looking at ObjectProcessor, there is so little involved in managing the __processedObject plug that we might as well just repeat that in FreezeTransform I reckon. I checked in SceneAlgo and as long as we use the same name for the plug, we'll still benefit from the fix for #5406.

[danieldresser-ie]

Copied in the implementation of the __processedObject plug. A bit of a hasty copy/paste job, but everything seems to be working OK.

[johnhaddon]

Thanks Daniel. Could you rebase this on the latest main please now that I've merged the MergeObjects PR. And while you're doing that, could you add a mention of the performance improvement in Changes.md. I also wonder if we're mimicking ObjectProcessor a bit too much - it feels like maybe just moving the hashProcessedObject/computeProcessedObject code inline into hash/compute might be a bit clearer, since we're treating the transform plug that way. Whichever you think best though...

[danieldresser-ie]

Removed hashProcessedObject/computeProcessedObject - I just thought the consistency might be nice for someone comparing to other nodes, but considering this code in isolation, it's definitely nicer this way.

Squashed it and added changelog, should be ready for merge.

[johnhaddon]

Rebased to fix merge conflict, added a Changes.md entry to mention cancellation support, and merged.