RE: setImmediate usage on the web

Hiroshi, I appreciate your participation on this discussion. To clarify, “Efficient Script Yielding” was created to allow JavaScript to efficiently use the CPU and conserve power in race to idle<http://dl.acm.org/citation.cfm?id=2095216> coding patterns. Nicholas Zakas detailed the case for setImmediate<http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/> and its use cases vs rAF, and setTimeout.

Ross, with regards to requestIdleCallback<https://docs.google.com/document/d/1ZgYOBi_39-N6AbjL99qesiDagaSTbpN0R6CrSVK8NE4/edit#heading=h.lobhanl56igp>, I’m happy to be corrected, but I feel like requestIdleCallback is setImmediate with an “best guess” at the idle time provided to the callback.  Apart from telling the callback how long they have to run, I’m not sure how they differ. With 5% usage on the web of setImmediate, it would be hard to abandon it and hard to understand why other browsers haven’t implemented the existing spec. We add features to the platform all the time and I get that. But this feels like an opportunity to extend the existing API rather than starting from scratch.

If you take a current example looks like this:
function emailClient() {
   setImmediate(checkSpelling);
}

function checkSpelling() {
   // do work
}

If we extended setImmediate to allow for an optional input parameter, new UA implementations would continue to execute this code and developers who are new to the API could do something like this to support new UAs and old alike:

function emailClient() {
     setImmediate(checkSpelling);
}
function checkSpelling(deadline) {
   if(!deadline) {
         // fallback behavior: do work
   } else {
      if(deadline.isExpired) {
         // do work
      }
   }
}

This approach immediately benefit power consumption and CPU utilization in other browsers before sites even had an opportunity to update their sites to the new version of the spec.





From: Hiroshi Kawada [mailto:kawada.hirosi@gmail.com]
Sent: Wednesday, June 24, 2015 2:55 AM
To: Todd Reifsteck
Cc: public-web-perf@w3.org
Subject: Re: setImmediate usage on the web

I'm sorry, but I didn't explain enough.

setImmediate has 3 use cases:

1. Executing after I/O(Layout,Rendering).

requestAnimationFrame covers this use case,  but it's not correct meaning. Real-world developers use setTimeout(fn,0). Microsoft developers uses setImmediate(fn). `setIdleTask` is the best solution.

2. Dividing heavy processing.

Generators(ES6) covers this use case, which contains Image decoding. Web Workers also can help this use case. Some developer use setImmediate/setTimeout, but it's incorrect.

3. Executing when thread are idle.

This use case is very similar to no.1. Developers may use setTimeout(fn,0) or setImmediate(fn).
requestAnimationFrame also covers this use cases. But it's not correct meaning. Generators(ES6) can help us, but sometimes it's not useful. It does not completely cover. `setIdleTask` is the best solution.





On Wed, Jun 24, 2015 at 5:28 PM, Todd Reifsteck <toddreif@microsoft.com<mailto:toddreif@microsoft.com>> wrote:
Although I agree the name is suboptimal, 5% real-world web usage in Microsoft Edge is quite high usage to consider renaming or removing an existing API. 5% real-world usage hints that there is some demand for the functionality the API provides even though it is only implemented in 1 browser.

Can you please elaborate on the ES6/7 feature that has the low priority callback characteristic of setImmediate?

-Todd

From: Hiroshi Kawada [mailto:kawada.hirosi@gmail.com<mailto:kawada.hirosi@gmail.com>]
Sent: Wednesday, June 24, 2015 12:09 AM
To: Todd Reifsteck
Cc: public-web-perf@w3.org<mailto:public-web-perf@w3.org>
Subject: Re: setImmediate usage on the web

I think setImmediate is too vague. Web developers just make callback executing after I/O(Layout/Rendering) or waiting for that thread gets idle. Some ES6 features that new browsers are already supported and requestAnimationFrame API covers this use case.

So, we need to choose these 3 idea :

1. rename setImmediate to setIdleTask ... separate out two use cases(requestAnimationFrame and setIdleTask).
2. remove this spec. ... ES6/7 will cover this use case.
3. keep on this spec ... waiting for other idea or usage.


On Tue, Jun 23, 2015 at 3:34 AM, Todd Reifsteck <toddreif@microsoft.com<mailto:toddreif@microsoft.com>> wrote:
I promised a few weeks ago to come back to the Web Performance Group with data on setImmediate usage within Microsoft Edge. Upon examining the data, I found that it required more parsing and analysis because the usage was much higher than I expected. What I discovered was that the usage was much higher in scenarios where setImmediate was guaranteed to be available such as Windows Store applications.

% of Navigations that include a usage of setImmediate

•         Microsoft Edge browser navigations—4.73%

•         All instances of edgehtml.dll (including apps)—21.88%

-Todd




--
KAWADA Hiroshi
Web Developer (JPN)
http://hiroshik.info/




--
KAWADA Hiroshi
Web Developer (JPN)
http://hiroshik.info/