922272 - Handle jQuery polymorphic selector argument better

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Jan de Mooij [:jandem]]

jQuery.fn.init is the main jQuery function. It starts like this (v1.6.4):

    if ( !selector ) {
        return this;
    }

    // Handle $(DOMElement)
    if ( selector.nodeType ) {
        ...
    }

    if ( selector === "body" && !context && document.body ) {
        ...
    }

    // Handle HTML strings
    if ( typeof selector === "string" ) {
        ...
    }

The problem is that jQuery itself calls this function and passes (1) document and (2) a function as selector argument. Then we run the benchmark and selector is a string 100% of the time. If we could compile this function and assume selector is a string, we could make most of these checks a lot faster (optimize away the typeof selector === "string", if (selector.nodeType) etc).

Usually we start gathering type information when the script is Baseline compiled so we wouldn't have this problem I think. Unfortunately this function is a constructor so we collect type information immediately (definite properties analysis).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.... jQuery.fn.init a constructor because of this bit:

	jQuery = function( selector, context ) {
		// The jQuery object is actually just the init constructor 'enhanced'
		return new jQuery.fn.init( selector, context, rootjQuery );
	},

?

Comment 2

[Brian Hackett [Laid off!]]

Well, the 'return this' early in the script means there won't be any definite properties.  A lame way to handle this would be to sniff for that bytecode pattern early in the script before any other uses of 'this' and don't bother analyzing (or baseline compiling) in that case.  An alternative would be to allow the analysis to run without baseline compiling the script first (and only baseline compile if definite properties were found), though that is tricky since the bytecode type map (which will be needed) is currently stored on the baseline script.

Comment 3

[Andrew Overholt [:overholt]]

Is this still something we'd like to do, Jan?

Comment 4

[Jan de Mooij [:jandem]]

We should be doing much better here now because our ICs now know how to optimize this part in comment 0 when selector is a string:

    if ( selector.nodeType ) {

I'm working on other IC optimizations atm, let's keep this open a bit longer and remeasure later.

Comment 5

[(no longer active)]

Kannan, what to do with this bug also?

Comment 6

[Kannan Vijayan [:djvj]]

p1.

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Jan de Mooij [:jandem] from comment #4)
> We should be doing much better here now because our ICs now know how to
> optimize this part in comment 0 when selector is a string:
> 
>     if ( selector.nodeType ) {
> 
> I'm working on other IC optimizations atm, let's keep this open a bit longer
> and remeasure later.

Is it possible to remeasure now?

Comment 8

[Jean Gong :jgong]

This doesn't seem like it will be fixed by 57 so I moving it to P2 for post 57 work.

Comment 9

[Naveed Ihsanullah [:naveed]]

Jan have you remeasured this?

Comment 10

[Jan de Mooij [:jandem]]

As mentioned in comment 4, we should do much better here nowadays. It has been 4 years and we don't have a testcase for this particular bug, so I think I'll just close this and we can file new bugs if we see more slowness here.