Fix performance degradation while trying to place object with a new combo in the editor.

[EVAST9919]

Closes #31428.
HitObjectPlacementBlueprint.UpdateTimeAndPosition() calls IHasComboInformation.UpdateComboInformation() in which bindables can be reassigned multiple times with the end result being the same, so triggering bound actions can be avoided.

master:
https://streamable.com/oa6ktq
pr:
https://streamable.com/bpm3ux

[bdach]

Next time please provide actual profiling results. Frame graph is not profiling.

As far as I can tell this is at most halving the number of assignments to the various bindables, which alone wouldn't fix the issue. What is probably fixing the issue is that reducing this code to a single assignment at the end of the method is reducing change callbacks firing because otherwise the bindable thrashes between intermediate values and the final complete values. If only final complete values are assigned to the bindables, the "is the bindable value already equal to this" checks framework-side early-return and thus change callbacks aren't fired.

Is this a correct interpretation of this diff? Seems fine if so, but that is very not obvious to me, and all of this information should be spelled out in the OP.

[bdach]

probably ok pending confirmation of above

[EVAST9919]

Next time please provide actual profiling results. Frame graph is not profiling.

This pr is only possible due to profiling (results of which could've been included in the OP, yes)
Recorded while doing the same actions on the video and shows a big difference on my end.

master	pr

reducing this code to a single assignment at the end of the method is reducing change callbacks firing because otherwise the bindable thrashes between intermediate values and the final complete values. If only final complete values are assigned to the bindables, the "is the bindable value already equal to this" checks framework-side early-return and thus change callbacks aren't fired.

"bindables can be reassigned multiple times with the end result being the same, so triggering bound actions can be avoided" in the OP means the same thing imo.

[bdach]

This pr is only possible due to profiling (results of which could've been included in the OP, yes)

Should have been. All performance optimisations should come with profiling results out of the gate. Especially if you already had the profiling results and was working off of them.

"bindables can be reassigned multiple times with the end result being the same, so triggering bound actions can be avoided" in the OP means the same thing imo.

I dunno I didn't read it that way.

I don't say this sort of thing to be a hardass and give you a difficult time, I say it because the lack of profiling results and a detailed explanation of the optimisation costs me review time. It's half an hour spent yesterday trying to understand what this does that I'm not getting back, and that is my only concern.

[bdach]

@peppy mentioned in passing on stream that he'd consider coalescing these two conditionals into a single one because the nesting makes it hard to read otherwise. I'm neither here or there on that, I could live with this version, but at least maybe it's a good thing to at least propose it.

[peppy]

Just a tip when including profiling screenshots: make sure the original method is visible in the new screenshot so the relative percentage usage can be compared to other methods in the same parent method.