875815 - Terrible performance on mootools $$("*") call

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Looking at http://dromaeo.com/?id=195568,195582 and in particular at the "DOM Query (Mootools)" section the first item is "Mootools - *".  On this item we're 10x slower than Chrome, though on the other items we're pretty similar, mostly.

A profile shows that it's all a mess.  Specifically:

1)  14% of the time is spent taking the slow fallback path through ion::GetPropertyIC::update.  I'm not quite sure why, though at least part of this seems to be calling HTMLFormElement resolve hooks or something?  And more is nativeLoookup.

2)  17% of the time is self time in js::Interpret(!).  The interpreter is also calling a bunch of ion::CanEnter, TypeMonitorResult, proxy_GetElement (which lands in HTMLCollectionBinding, doing an own-prop get), etc, etc.  The total fraction of time under js::Interpret but not under JITs is about 31% (!!).

3)  About 18% of the time is self time in baseline jitcode.

4)  6% js::ion::ProxyGet calling into HTMLCollectionBinding.

5)  6% js::ion:DoGetNameFallback calling into js::GetScopeName (which is 3% of
    total time).

6)  Various DoTypeUpdateFallback and DoTypeMonitorFallback being called from
    baseline jitcode, afaict, is another 6-7%.

I guess the most important question to start with is why we're spending so much of our time in baseline, and worse yet in interp....

Comment 1

[Boris Zbarsky [:bzbarsky]]

Some more data.  $$ looks like this:

  if (arguments.length == 1 && typeof selector == 'string')
    return this.document.getElements(selector);

(that's the path we should end up taking every time through it) and then the only other weird part in the function is:

  var args = Array.flatten(arguments);

Not sure whether this prevents ion-compilation of $$ itself.

getElements looks like this:

  	getElements: function(tags, nocash){
		tags = tags.split(',');
		var elements = [];
		var ddup = (tags.length > 1);
		tags.each(function(tag){
			var partial = this.getElementsByTagName(tag.trim());
			(ddup) ? elements.extend(partial) : elements = partial;
		}, this);
		return new Elements(elements, {ddup: ddup, cash: !nocash});
	}

In this case this should end up doing a single call to getElementsByTagName and then call the |new Elements| thing.  Then there's a bunch of stuff that happend in the initialize() function in Elements, including walking the list with [i], etc...  Not sure which parts of this are ending up in interp, exactly and why.

Comment 2

[Kannan Vijayan [:djvj]]

All of that code should compile with both Ion and Baseline.

Comment 3

[Guilherme Lima]

Testing Firefox 34 x Chrome 39:
http://dromaeo.com/?id=232094,232093
Mootools - *	314.03runs/s ±73.30%	1188.82runs/s ±3.18%	
Firefox still almost 4x slower.

Comment 4

[Boris Zbarsky [:bzbarsky]]

We should probably retest now that bug 1323190 is fixed.

Comment 5

[Jan de Mooij [:jandem]]

Bug 965992 also blocks a mootools bug, so we might want to wait for that to land as well.

Comment 6

[Tom S [:evilpie]]

Mootools - * is still pretty slow:  432.44runs/s with just the IC from bug 1323190 and 491.11runs/s when using my local Proxy::get inlining patch.

Comment 7

[Matthew Gaudet (he/him) [:mgaudet]]

We're still slower; 4500 vs 6500. But we're not nearly at 10x, and mootools is fading away AIUI.