We don't try to parse the selector in JS until we run it through the native method. If the native method throws an exception, we try parsing it ourselves. The only other way we could know to avoid it would be to parse the string ourselves, which would penalize people who use just standard selectors.

In the talks I do, I strongly recommend against :visible or :hidden as selectors. Besides being jQuery custom selectors and having to take the Sizzle path after being rejected by native methods, they also force layout if it's dirty. Most of the time it's easily trackable by classes. The docs warn about this as well.

In the talks I do, I strongly recommend against :visible or :hidden as selectors

Great. In this and with Wikipedia's new visual editor, a tremendous amount of the app's slowness is directly attributable to using those. It's baaad. But anyway, moving on.

If the native method throws an exception, we try parsing it ourselves.

I see that now. In the case of obviously invalid selectors, it'd be better to not even go down the patch of bouncing off the exception.

Follow the total time column above. is() is ~111ms. In the end, 69ms of that is matchesSelector just returning an exception and 18ms is Sizzle() doing its thing. (which it does, everytime)

The overhead to throw an extra regex test along with the other two here is going to be sub-millisecond on this timescale. And since we're already running two regex's against the string, the overall VM overhead will be minimal.

I'll pull in @timmywil and @gibson042 here, maybe we could do a quick regex to look for obvious offenders? Discussing the issue in IRC, perhaps we should move things like :hidden and other really slow custom selectors to jQuery Migrate in 4.0. Of course that brings up some Sizzle questions as well.

This suggestion is essentially to match custom pseudos in rbuggyQSA, which would save legitimate uses but force false positives (e.g., [attr-name=":visible"]) down the slow path—in other words, a net win. However, identifying them will be a trick, given that our extension mechanism is just property assignment to the same object containing matchers for standard pseudos.

As for removing custom pseudos from standard builds, I see :hidden, :visible, and :animated in core, and would not mourn the loss of any (although that last one is essentially impossible to add back without knowledge of undocumented effects internals). We may also want to look at jQuery UI while we're at it: http://api.jqueryui.com/category/selectors/.

I'm a little surprised it takes that long for webkitMatchesSelector to parse the selector and determine whether it's invalid. I wonder if that can be improved natively.

Could we cache the fact that the selector failed qSA or mS and skip it for subsequent ones? Actually, if you have an entry in the Sizzle cache doesn't that mean it must have failed previously?

Hmm, that's not a bad idea. @gibson042 ?

Yeah, I like that a lot. It's not a panacea when the selectors theirselves are different, but it avoids a lot of pain for little effort.

Issue opened here. That should address this issue fairly well with little cost, as gibson said. We'll close this issue when we merge in that Sizzle update.

@paulirish You'll be happy to know that we now see a 1600% improvement on :visible/:hidden. jquery/sizzle#315 (comment)

Wow. Amazing!

Wow! This is so cool!