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

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.

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.

Thanks, Jason



From: 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
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