Bug 586201: Throttle refresh drivers in background tabs. r=roc, a=roc
Bug 590422: Stop futzing with our timer scheduling and just schedule them. r=brendan
cheers,
mike
On 2010-08-27, at 8:42 AM, Nobody wrote:
> Regression: tscroll increase 40.7% on XP Firefox
> Previous results:
> 11439.7 from build 20100826194911 of revision 65f20938e5d6 at 2010-08-26 21:19:42 on talos-r3-xp-023 run # 0
> New results:
> 16097.9 from build 20100826222852 of revision 0078400b865b at 2010-08-26 23:58:52 on talos-r3-xp-050 run # 0
> http://mzl.la/adev13
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=65f20938e5d6&tochange=0078400b865b
> _______________________________________________
> dev-tree-management mailing list
> dev-tree-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
Yes. Those are also the patches which show a Tp improvement (1-4%
depending on platform) and a Tdhtml increase (1-4% depending on
platform) and a 4% Tsvg increase.
I'm betting that bug 590422 is responsible for all of these by affecting
slightly when setTimeout timers fire (especially because the other bug
only has an effect on background tabs). I'll try backing out the timer
change to see what happens; while a 3% increase in Tdhtml due to us
firing timers at closer to the right times, that seems unlikely to cause
a tscroll change this big.
That said... where does the tscroll source live? It's not listed at
https://wiki.mozilla.org/Performance:Tinderbox_Tests and I'd really like
to see what the test actually does.
-Boris
cheers,
mike
I was pointed to
http://mxr.mozilla.org/mozilla/source/testing/performance/talos/page_load_test/scroll/
on irc.
Assuming this is the right test, the test structure is basically:
var start = new Date();
var intervalId = setInterval(function () {
lastScrollPos = target.scrollTop;
target.scrollTop += stepSize;
if (target.scrollTop == lastScrollPos) {
clearInterval(intervalId);
var totalDuration = new Date() - start;
var avg = totalDuration/(target.scrollTop/stepSize);
tpRecordTime(Math.ceil(avg*1000)); // record microseconds
}
}, 10);
}
In other words, this test only measures scrolling if each scroll
operation takes more than 10ms. If it takes less than 10ms, then it's
just measuring how close to 10ms the timer interval is.
I can certainly believe that removing the delay line stuff might have
made a 10ms interval actually happen at closer to 15ms specifically on
Windows XP; we've had issues with that on that particular OS before....
Still enough to back the patch out for, if correct.
-Boris
> On 8/27/10 2:57 PM, Mike Beltzner wrote:
>> Jeff may be able to answer your questions about where the test lives, and what a 40.7% regression implies. My layman's interpretation is: slower scrolling.
>
> I was pointed to http://mxr.mozilla.org/mozilla/source/testing/performance/talos/page_load_test/scroll/ on irc.
>
> Assuming this is the right test, the test structure is basically:
>
> var start = new Date();
> var intervalId = setInterval(function () {
> lastScrollPos = target.scrollTop;
> target.scrollTop += stepSize;
> if (target.scrollTop == lastScrollPos) {
> clearInterval(intervalId);
> var totalDuration = new Date() - start;
> var avg = totalDuration/(target.scrollTop/stepSize);
> tpRecordTime(Math.ceil(avg*1000)); // record microseconds
> }
> }, 10);
> }
>
> In other words, this test only measures scrolling if each scroll operation takes more than 10ms. If it takes less than 10ms, then it's just measuring how close to 10ms the timer interval is.
>
Boris, any better/additional way to test scroll perf?
Haven't thought of one yet, but thinking. The problem is that some of
the work involved is fundamentally async (and soon will be on a
different thread or in a different process altogether), so the only way
to measure is to measure the total time taken.... but then you need to
make sure that your scrolling is what determines that time.
-Boris