[whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with "nonzero" (default) and "evenodd" options

[Boris Zbarsky]

On 1/9/13 1:20 AM, Rik Cabanier wrote:
> Also, would there be a performance impact of having a string
> argument for a call that happens very frequently?

That's an excellent question.  The answer is that it depends.

Here's a testcase that exercises setting a property to a WebIDL enum and 
measures the time in ns per property set:

<script>
   var xhr = new XMLHttpRequest;
   xhr.open("GET", "");
   var count = 1000000;
   var start = new Date;
   for (var i = 0; i < count; ++i) {
     xhr.responseType = "text";
   }
   var stop = new Date;
   alert((stop - start) / count * 1e6);
</script>

What I see on my hardware in a current Firefox nightly is that this 
takes about 27ns per set (this is on a 6-month-old fast laptop, for 
context, but of course you can measure on the hardware of your choice). 
  About 8-10ns of that is the general overhead associated with the loop 
counter, the setter invocation, etc.  If my profiler is not lying to me, 
another several ns is the actual implementation of the C++ responseType 
setter.  The rest of the time is spent dealing with the string.  For 
what it's worth, it's possible we could make the string bit faster for 
cases when a constant string is being used, as above; I'd have to think 
about it a bit.

Here's a similar testcase that exercises a boolean:

<script>
   var xhr = new XMLHttpRequest;
   xhr.open("GET", "");
   var count = 1000000;
   var start = new Date;
   for (var i = 0; i < count; ++i) {
     xhr.withCredentials = false;
   }
   var stop = new Date;
   alert((stop - start) / count * 1e6);
</script>

The time I see now is closer to 12-13ns.  So there is definitely 
overhead associated with the string: about 15ns per call.  How many 
calls are we expecting people to make here?

But as I said, it depends.  The numbers are quite different in other 
UAs.  Testing a Chrome 25 dev channel build, a WebKit nightly (labeled 
"Safari" below), and and Opera build that claims to be "12.50 internal", 
I get numbers like so, in ns (all with a few ns plus or minus; I'm 
leaving off the error bars):

              enum    boolean
Firefox       27       13
Safari        51       33
Chrome        58       40
Opera        158       82

so how long this stuff takes is clearly pretty implementation-dependent. 
  And note that these are upper bounds, since I have no guarantees that 
the time taken by the actual C++ setters is negligible in these case 
(except for Firefox, where profiles show that it is).  For example, 
Chrome gets about 30% slower if I set responseType to "document" instead 
of "text", as far as I can tell, and that might be due to the C++ side.

Hope that helps,
Boris

P.S.  For a real fun time, try doing xhr.responseType = false, as I 
accidentally did at some point while testing this and look at the 
resulting numbers.  ;)