[Bug 24115] Introduce CSS.isValidSelector()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24115

--- Comment #7 from Boris Zbarsky <bzbarsky@mit.edu> ---
> I think a slightly more realistic benchmark doesn't use the same string every
> time

This has the opposite problem: it uses a different string pretty much every
time.  That's not how real-life use cases of this work; in practice they use
some fairly small number of strings, not 100000 different ones.

Furthermore, it's creating the strings via string concatenation, which is also
not how this stuff is typically used and adds overhead that's the same in both
the throwing and non-throwing case, reducing the difference between them.  I
think http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2701 is a
closer approximation of how this would work in real life, but still ignoring
the stack depth bit for throwing.

> The throwing path is still a lot slower in Gecko and Blink, but in Presto the
> throwing code path isn't that slow.

Throwing in today's SpiderMonkey (and I suspect V8) has to reconstruct stack
data that the JIT normally doesn't keep track of during execution for
perfomance reasons.  It's obviously possible to make throwing faster, by
tracking that data all along, but mostly at the expense of making non-throwing
script slower, which is a tough sell.

That said, there is definitely low-hanging fruit for throwing at least in Gecko
that we're fixing.  On your testcase, I see numbers like so:

Presto (12.16, fwiw):  4670 3880
Recent Firefox nightly: 1470 9530
My local build with some changes to throwing: 1450 9160

I can probably get that throwing number down to about 6000 or so, I suspect,
based on profiles.  But I doubt it'll get anywhere near as fast as the
non-throwing case.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 18 December 2013 15:57:42 UTC