W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 12 Mar 2013 01:14:46 -0400
Message-ID: <513EB9C6.9090302@mit.edu>
To: whatwg@lists.whatwg.org
On 3/12/13 12:56 AM, Glenn Maynard wrote:
> (I suppose a simpler optimization is simply copy-on-access: make a copy of
> the backing store if the .data property of ImageData is accessed.

This may actually be a harder optimization to make in practice.

For example, Gecko+SpiderMonkey has the .data getter on ImageData 
objects annotated as being pure and returning a constant value.  This 
means that if you have code like this:

   img.data[0] = 1;
   img.data[1] = 2;

CSE can get rid of the redundant .data gets.  Similarly, .data gets can 
be loop-hoisted in many cases.

Based on some spot measurements, at first glance WebKit+V8 has somewhat 
similar behavior, however they get there (e.g. Gecko used to have a 
behavior somewhat like this by simply making ImageData be plain-vanilla 
JS objects with an own "data" property instead of WebIDL objects, and 
then the JIT can optimize gets using normal alias analysis techniques 
for slot gets).

But if .data can have side-effects the ability to do these sort of 
optimizations goes out the window and you get a much slower .data 
getter.  So you get a faster putImageData but the tradeoff is slower 
imagedata manipulation unless the script author performs the CSE and 
LICM optimizations by hand (which some do and some don't).

So there's no really good way to make this optimization without 
degrading performance of things people commonly do....

Received on Tuesday, 12 March 2013 05:15:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:56 UTC