110591 - DOMClassInfo interface shortcuts twice as fast as Components.interface.*

Status: VERIFIED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Fabian Guisset]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
BuildID:    2001102311

Here's an interesting one:

function isAnchor(node) {
var list = new Array();
for (var i = 0; i < 100000; i++) {
  list[i] = node instanceof HTMLAnchorElement;
}
}

runs twice (7seconds vs 14 seconds in my test) as fast as

function isAnchor(node) {
for (var i = 0; i < 100000; i++) {
  list[i] = node instanceof Components.interfaces.nsIDOMHTMLAnchorElement;
}
}

Any idea why? (I sure hope it's not because of XPCOM ;-)
Testcase coming up.


Reproducible: Always
Steps to Reproduce:
1. Run the attached testcase
2.
3.

Actual Results:  HTMLAnchorElement comparison is twice as fast as
Components.interfaces.nsIDOMHTMLAnchorElement comparison

Expected Results:  Same speed.

Athlon 1Ghz 256MB RAM on linux Mandrake8.1. Tested on 0.9.5.

Comment 1

[Fabian Guisset]

Attachment: Testcase

50000 runs. First button uses HTMLInputElement, second button uses
Components.interfaces.nsIDOMHTMLInputElement

Comment 2

[Fabian Guisset]

Attachment: Added timing methods and a choice between 10k and 50k loops.

It's not just twice as fast... on my computer it's about 30 times as fast
(???). Is it because HTMLInputElement is cached as a property of the global
object while Components.interfaces.* is resolved everytime we access it?

Comment 3

[Axel Hecht]

today's tip gives me 1970 vs 2418 on the 10k test, 9752 vs 12709 on 50k.
A few days back build gives 10391 vs 13346 on the 50k test, and 2069 vs 2634
on 10k.
That's a ratio of 0.79 and 0.78 a few days back, 0.81 and 0.77 today, (10, 50k)

Comment 4

[Fabian Guisset]

OK I re-tested with both Mozilla 0.9.5 and a nightly build on win2k Athlon 1Ghz
256MB RAM.
It seems we have a huge regression on our hands here.
0.9.5:
******************
Shortcut 10k: 15ms    |   Components.* 10k: 300ms
Shortcut 50k: 75ms    |   Components.* 50k: 1500ms
                      |
Nightly:              |
******************    |
Shortcut 10k: 235ms   |   Components.* 10k: 300ms
Shortcut 50k: 1190ms  |   Components.* 50k: 1600ms

So the Components.* times are steady, but the DOMClassInfo shortcut times were
severely regressed!
I seem to remember a checkin to remove the security manager optimization. Might
it be the cause?

Comment 5

[Johnny Stenback (:jst)]

The code:

  for (var i = 0; i < 100000; i++) {
    list[i] = node instanceof Components.interfaces.nsIDOMHTMLAnchorElement;
  }

is bound to be slower than:

  for (var i = 0; i < 100000; i++) {
    list[i] = node instanceof HTMLAnchorElement;
  }

since there's more work that needs to be done when running the former compared
to when running the latter (more '.'s in the code, more expensive
implementations, ...).

The regression is due to the lack of the security check optimization we used to
have in the DOM code, it was taken out because it exposed exploitable security
holes. New optimization on it's way, once that's checked in I'm leaning towards
marking this WONTFIX.

Comment 6

[Fabian Guisset]

What you're saying is scary :-)
I'm fine with marking this WONTFIX. I wonder what the chrome perf would be if we
optimized every single of js to have as few characters as possible ;-)

Comment 7

[Fabian Guisset]

In 0.9.7 the DOM shortcut is once again much faster than the full Components.*
path (30 times faster, is that possible??). Since it seems to be due to nothing
particular (see comment 5), i'm marking this WONTFIX.

Comment 8

[Hixie (not reading bugmail)]

verified per module owner