RE: [Efficient Script Yielding] Re: [minutes] 20110706 Web Performance WG Teleconference #40

That's exactly my point. Timers and callbacks are used for many web programming patterns. If those changes don't result in visible feedback the timer frequency can't impact performance. Let's take a theoretical XHR example of a brokerage website that downloades realtime stock quotes every 4ms through a nested setTimeout and updates the DOM with the results when they're received. Assuming consistent latency/server responses the page would be receiving these streaming network quotes every 4ms and displaying the results. Only every 4.175 stock quote updates will be visible to the user. The only way a web developer can provide results from any timer/callback pattern is visually, meaning 16.7ms is the fastest any callback pattern should need to run.

There's either a pattern where high frequency timer resolutions make sense in the web platform, in which case setImmediate provides many benefits over HTML5's defined 4ms timer frequency. Or there's not a pattern where high frequency timers make sense in which case it feels like HTML5's timer frequency should be clamped at 16.7ms to improve power consumption of the web platform.

This goes back to my question... Would you please explain to the working group what real world scenarios lead to Chrome (and later HTML5) decreasing the setTimeout/setInterval frequency to 1ms and later clamping at 4ms?




From: James Robinson [mailto:jamesr@google.com]
Sent: Wednesday, July 13, 2011 12:24 AM
To: Jason Weber
Cc: Ian Hickson; public-web-perf@w3.org; Sigbjørn Vik
Subject: Re: [Efficient Script Yielding] Re: [minutes] 20110706 Web Performance WG Teleconference #40

On Tue, Jul 12, 2011 at 8:47 PM, Jason Weber <jweber@microsoft.com<mailto:jweber@microsoft.com>> wrote:
James/Ian,

Can you explain to the working group what real world scenarios lead to Chrome (and later HTML5) decreasing the setTimeout/setInterval frequency to 1ms and later clamping at 4ms? Those are the exact scenarios where setImmediate makes sense today.

The reason that nested timers are clamped at 4ms is exactly the reason why setImmediate() does not make sense.



If those scenarios don't exist we should discuss increasing the HTML5 setTimeout/setInterval frequency to 16.7ms (visual refresh) which is the fastest a web application could perform work that would result in a visual change to the user. That would allow the web to move away from CPU interrupts altogether and begin to address the negative power implications of HTML5 on x86/x64 platforms.

This makes the false assumption that timers are always related to visual effects.  Authors who are trying to schedule work tied to the visual refresh rate should generally be using requestAnimationFrame().  If there are use cases for scheduling work tied to visual refresh that requestAnimationFrame() does not cover then we should consider those use cases and see what we can come up with.

- James

Thanks, Jason



From: public-web-perf-request@w3.org<mailto:public-web-perf-request@w3.org> [mailto:public-web-perf-request@w3.org<mailto:public-web-perf-request@w3.org>] On Behalf Of James Robinson
Sent: Tuesday, July 12, 2011 7:00 PM
To: Sigbjørn Vik
Cc: public-web-perf@w3.org<mailto:public-web-perf@w3.org>
Subject: Re: [Efficient Script Yielding] Re: [minutes] 20110706 Web Performance WG Teleconference #40

On Tue, Jul 12, 2011 at 3:07 AM, Sigbjørn Vik <sigbjorn@opera.com<mailto:sigbjorn@opera.com>> wrote:
On Thu, 07 Jul 2011 00:28:02 +0200, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
Meeting Summary:


3.      Feedback and discussion on the setImmediate specification

There are a few discussions happening on the mailing list regarding feedback and clarifications on the current setImmediate design, including clamping, allowing the UA to delay the event, script based schedulers, frequency and power consumption benefits of this API. In this call, pros and cons were discussed for not clamping the setImmediate API. It was decided to continue the discussion on the mailing list.

Should we try to find use cases for the specification before we start discussing the details? It would seem that how we choose to implement it depends on what we want it to do. I have seen several calls for the use cases on this list, but so far no consensus.

The only use case I have seen so far is this:
1. Allow a script to tell the browser "If there are any other scripts to be executed, you may do so now, but please come back to me immediately afterwards (faster than a clamp would do)"
(I do not consider working around browser bugs (e.g. frozen UI) to be real use cases.)

If this is the main use case, it would heavily influence the clamping discussion. setImmediate would also be identical to setTimeout, so we could also consider extending setTimeout with an additional parameter: boolean yes_I_really_mean_the_timeout_I_wrote

I have also seen calls for a way to tell the browser "Please do all layout updates, and then come back to me". setImmediate does not (currently) address this use case, and the solution to this might end up looking quite different.

In any case, I'd like to work out the use cases before going into the details of the solution.

I agree.  We still haven't seen any concrete use cases of pages in the wild or of contrived, realistic test cases where setImmediate() seems to be the right solution.  Without a clear idea of what problem or problems we're trying to solve, it's impossible to come up with a good solution.

- James



--
Sigbjørn Vik
Quality Assurance
Opera Software