Closed
Bug 590041
Opened 14 years ago
Closed 1 year ago
Investigate why our handling of prototype stuff in dromaeo is so slow
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: bzbarsky, Unassigned)
References
(Blocks 1 open bug)
Details
I was looking at the numbers at http://dromaeo.com/?jslib-style-prot&numTests=1 and in particular the numbers for show(). The summary is that Chrome is at 1660runs/s or so, Safari 5 at 565, and JM+TM tip (which is faster than TM or m-c) at 170. A profile shows that:
1) 7% is spent under XPC_WN_JSOpThisObject (getting subject principals, getting
wrappers, etc.)
2) 75% of the time is spent in the js engine (70% in libmozjs, 5% in realloc
calls).
3) 12% is spent in something resembling DOM code (under quickstubs, etc).
If I focus on libmozjs and blame all unknown library stuff to callers, then the "heavy" profile looks like this:
15% JaegerShot
5% InvokeCommon
3% tiny_malloc_from_free_list
3% Invoke
3% js_LookupPropertyWithFlags
2% js_fun_call
2% js_fun_apply
2% js_NativeGet
2% js_NewFinalizableGCThing
2% array_extra
2% stubs::Call
2% array_concat
etc, etc.
The actual testcase is basically calling this a bunch of times:
div.invoke("show");
where we have:
invoke: function(method) {
var args = $A(arguments).slice(1);
return this.map(function(value) {
return value[method].apply(value, args);
});
},
and:
map: Enumerable.collect,
and:
collect: function(iterator, context) {
iterator = iterator || Prototype.K;
var results = [];
this.each(function(value, index) {
results.push(iterator.call(context, value, index));
});
return results;
},
and:
each: function(iterator, context) {
var index = 0;
try {
this._each(function(value) {
iterator.call(context, value, index++);
});
} catch (e) {
if (e != $break) throw e;
}
return this;
},
and:
_each: function(iterator) {
for (var i = 0, length = this.length; i < length; i++)
iterator(this[i]);
},
Eventually all this gunk calls:
show: function(element) {
element = $(element);
element.style.display = '';
return element;
},
which is where the work happens, because |div| above is some sort of collection containing exactly one element, and the gunk basically ends up doing element["show"].apply(element), I think. It just takes a ... roundabout way of getting there. Needless to say, the stack looks like the usual array_extra/call/call/apply/apply nastiness.
Oh, and that $A thing above looks like this:
function $A(iterable) {
if (!iterable) return [];
if (iterable.toArray) return iterable.toArray();
var length = iterable.length || 0, results = new Array(length);
while (length--) results[length] = iterable[length];
return results;
/// return Array.slice(iterable);
}
Reporter | ||
Comment 1•12 years ago
|
||
This is basically ending up mostly in JM, and mostly in stubcalls...
I wonder whether baseline will help here at all.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
Comment 2•1 year ago
|
||
13 year old profiling is probably not relevant any more.
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•