[Webkit-unassigned] [Bug 235114] New: Massive variation in microbenchmark results when tab returns to foreground
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Jan 12 07:43:01 PST 2022
Bug ID: 235114
Summary: Massive variation in microbenchmark results when tab
returns to foreground
Version: Safari 15
Hardware: iPhone / iPad
OS: iOS 15
Component: New Bugs
Assignee: webkit-unassigned at lists.webkit.org
Reporter: simontaylor1 at ntlworld.com
This is a weird one...
I've got a simple microbenchmark that counts how many times Math.random() can be called in a single performance.now() tick (1ms on current iOS Safari). The idea is this provides a metric for the the current JS thread CPU performance (which varies depending on if it is running on an efficiency or performance core, and clock frequency). This is scheduled in a requestAnimationFrame loop.
The page also has an option to further busy-loop in the rAF callback so the whole thing takes 20ms - checking with System Trace in Instruments this seems to reliably trigger the content thread being moved up to a Performance core, and gives higher call counts in the microbenchmark. I believe this is resulting in consistently high clocks but Instruments does not expose this data so I can't be 100% sure.
Without the busy-loop option enabled the counts drop massively as the thread is moved to an efficiency core and clock speeds can be reduced. Interacting with the page (pinch zoom etc) does give a boost in the numbers, reflecting frequency ramping up to deal with the interaction and keep everything smooth. So far, all is as expected.
Here's the weird thing: it looks like there are two distinct "operating points" for the microbenchmark results, and which one you get varies with page reload, or with events that cause the tab to make a background / foreground transition (tab switch, app switch, lock screen, etc).
On my iPhone 12 Pro, iOS 15.2 the "fast" operating point has ~4k calls without busy looping and ~30k calls with busy looping. The "slow" operating point is ~1.2k without busy looping and ~12k with busy looping. These numbers seem to remain pretty consistent as long as the tab stays on screen, and only change on a background / foreground or reload event.
I also have an iPhone 12 Mini with iOS 14.8.1, and the numbers are very similar to the "fast" operating point mentioned above. So I believe this to be an iOS 15.x regression.
I've also been able to reproduce on an iPod touch 7 on 15.2.
The best guess I have to explain the observed behaviour here is that some bug in tab re-awakening means it ends up using code from a lower JIT tier?
This came to light in my testing for Bug 235002 - note in either operating point for the microbenchmark, the webgl timings look consistent, so I do believe the clocks are consistent. One difference is on refresh the full webGL demo page seems to be in the "slow" mode for the benchmark but the simpler example seems to start out more often in "fast" mode. Some issue with tiering up in general that depends on the code size could be at play?
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-unassigned