Hi Team, While going through Blink's commit, came across another potential performance optimization: Blink Commit - https://chromium.googlesource.com/chromium/blink/+/143faa0607149758526318a98757a3055197cb0f WebKit Commit - https://searchfox.org/wubkat/source/Source/WebCore/platform/LayoutUnit.h#61 & https://searchfox.org/wubkat/source/Source/WebCore/platform/LayoutUnit.h#161 & https://searchfox.org/wubkat/source/Source/WebCore/platform/LayoutUnit.h#170 Just wanted to raise it for input. Thanks!
<rdar://problem/104441420>
Interesting. I wonder if this is a measurable performance improvement.
I started an A/B test to see if it's measurable.
Pull request: https://github.com/Webkit/WebKit/pull/8853
Was the speedup confirmed?
(In reply to Simon Fraser (smfr) from comment #5) > Was the speedup confirmed? A/B test is running now. I wanted to put the PR up to check correctness.
I messed up the perf test, and am running them again now. :-(
MotionMark has a small (0.18%) improvement, but is not statistically significant. Waiting for PLT results.
Performance A/B Results: iOS 16 (iPad Pro) * MotionMark: 0.18% better (insignificant) * PLT5: 0.52% better (insignificant) macOS 13, M1 MacBook Air * MotionMark: 1.79% better (insignificant) * PLT5: 0.23% better (insignificant) macOS 13, Intel iMac * MotionMark: 0.28% worse (insignificant) * PLT5: 0.17% better (insignificant)
There doesn't seem to be a measurable win on this change, so let's not add the complexity (and less-readable code).
Committed 260422@main (3fdb8cf70b8a): <https://commits.webkit.org/260422@main> Reviewed commits have been landed. Closing PR #8853 and removing active labels.
Looks like we ended up landing this anyway. Should it be reverted then?
(In reply to Alexey Proskuryakov from comment #12) > Looks like we ended up landing this anyway. Should it be reverted then? Sorry, that's my bad. I hadn't seen the discussion on the bugzilla side. I'll post micro-benchmark numbers today. The new code is simpler (less branching). We can decide whether to revert or not then.
Not surprised we haven't seen any perf improvements on non-micro benchmarks as I think these functions are not used too much anymore after going full-subpixel layout/rendering (other than some in some DOM api) and their usage should be trending down.
With 100000000 random values (ran 3 times each): * floor: Before: 112.52 ms After: 79.46ms (29% faster) * round: Before: 192.19ms After: 97.04ms (50% faster)