Boris Zbarsky [:bzbarsky] Reporter
	Description • 12 years ago

I was looking at the lastChild testcase at http://dromaeo.com/?dom-tra&numTests=1 (you can see the source at <http://dromaeo.com/tests/dom-traverse.html>) and it looks like we end up not doing the fast dom property get here.  The reason is that this thing is walking over the DOM and there are 17 different types of nodes in there.  And each one is added to 10+ type sets, looks like.  So we hit CONTRIBUTION_LIMIT and mark the whole thing as unknown object, and then can't do the fast DOM stuff anymore.

Brian tells me that after bug 804676 we may be able to revamp CONTRIBUTION_LIMIT to be less likely to be hit.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 1 • 12 years ago

Oh, and the point is that the less like a microbenchmark your code is the more likely this is to be a problem.  On the other hand, the fewer kinds of HTML elements you use (e.g. building a spreadsheet out of divs), the less likely it's to be a problem...

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 2 • 12 years ago

I just figured out today that this is in fact making all the following benchmarks in that test run without the fast DOM stuff, because those are touching the same nodes, which have the same typeobjects...

So just fixing this will be a nice big win on the nextSibling/previousSibling tests too.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 3 • 11 years ago

When this is fixed, we should retest on http://jsperf.com/demo-of-microbenchmark-silliness/ to see whether it fixes the TI fail there on the .id benchmark.

	Till Schneidereit [:till] Assignee
	Comment 4 • 11 years ago

As advertised

	Till Schneidereit [:till] Assignee
	Comment 5 • 11 years ago

> As advertised

Oh, that's not entirely true. It also changes TYPE_FLAG_OBJECT_COUNT_MASK to 0x1ff00, resulting in TYPE_FLAG_OBJECT_COUNT_LIMIT being 31 instead of 255.

	Brian Hackett [Laid off!]
	Comment 6 • 11 years ago

Comment on attachment 775694 [details] [diff] [review]
rm TypeObject::CONTRIBUTION_LIMIT and TypeObject::contribution.

Review of attachment 775694 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jsinfer.h
@@ -982,5 @@
> -     * later, and we want to ensure in such cases that our time/space complexity
> -     * is linear, not worst-case cubic as it would otherwise be.
> -     */
> -    uint32_t contribution;
> -    static const uint32_t CONTRIBUTION_LIMIT = 2000;

I think this will need to be replaced with a padding field when #if JS_BITS_PER_WORD == 32

	Till Schneidereit [:till] Assignee
	Comment 7 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/e1536ff0cb92

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 8 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/e1536ff0cb92