W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2011

Re: Efficient Script Yielding - First Editors Draft

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Wed, 29 Jun 2011 17:33:18 +0200
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <op.vxuf5sim41y844@id-c0735.oslo.osa>
Hi

We (Opera) are not quite certain about this proposal. It seems to be  
offloading browser responsibilities onto developers, and not solving the  
issue in any case. As browsers have to implement the ability to yield in  
arbitrary locations to implement this spec, they might as well do it when  
there is a need, not just when it is called by developers. The spec will  
make no impact on the majority of scripts, make developers have to learn  
one more feature (and use it correctly), and won't fix much for mobiles  
anyway, as scripts there run much slower than on desktop. (To fix it for  
mobiles, developers have to sprinkle their code generously with yields  
everywhere, in which case there is little point.)

It is also not going to fix e.g. long running regexps or other similar  
problems, those have to be fixed in the browser anyway.

continues below...

On Wed, 29 Jun 2011 00:17:06 +0200, Jason Weber <jweber@microsoft.com>  
wrote:

> Today, browsers don't process events while long running scripts are  
> executing. This includes everything from UI updates, to user input, to  
> end user features like spell checking. Even though the JavaScript may be  
> manipulating the DOM or updating styles, these updates aren't presented  
> to the user until after the script yields. To allow applications to  
> remain responsive and to process visual changes, web developers are  
> forced to sprinkle setTimeouts throughout their code allowing the  
> browser to process pending work and then call script back at a future  
> time.

This is only true for some browsers. Other browsers, like Opera, handle  
this without any issues, and has done so for many years. In our opinion,  
this is how it should be handled, feel free to try it out to see how this  
can be done. We have had to implement support for this to support the  
whole range of CPUs we ship on, where all, even slow, CPUs should be able  
to handle the same existing pages and scripts. The suggested spec would  
not solve this issue.

But we remain realistic. Browsers need to implement support for yielding  
one way or another. A spec will not change the difficulty of doing so, but  
if having a spec is what is required for other browsers to implement this  
and move the web forwards, then we have no objections. We would implement  
support for the suggested javascript API, but might potentially ignore it  
and continue to use our existing implementation.

A spec could instead simply say that browsers should yield regularily and  
automatically...

-- 
Sigbjørn Vik
Quality Assurance
Opera Software
Received on Wednesday, 29 June 2011 15:33:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 June 2011 15:33:27 GMT