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

Thanks for investigating this!
I opened a moderately complex file [1] and it had 19200 fills. The overhead
in ms then becomes
             enum    boolean
Firefox      .5         .25
Safari        .9         .6
Chrome     1.1       8
Opera        3         1.6

This is assuming that the extra parsing time and validation on the c++ side
take no time.
A quick search on the web shows that mobile browsers are about 8 times
slower.

Considering that the file takes a couple of seconds to render, it seems
that the overhead is negligible.

1:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/showcase/illustrator/pdfs/magic-paintbrush-howto.pdf

On Wed, Jan 9, 2013 at 9:13 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.  ;)
>

Received on Wednesday, 9 January 2013 18:50:19 UTC