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




18 years ago
12 days ago


(Reporter: fabian, Assigned: jst)




Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



18 years ago
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

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

18 years ago
Posted file Testcase (obsolete) —
50000 runs. First button uses HTMLInputElement, second button uses


18 years ago
Keywords: perf

Comment 2

18 years ago
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?
Attachment #58214 - Attachment is obsolete: true

Comment 3

18 years ago
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

18 years ago
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.
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

18 years ago
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

18 years ago
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

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → WONTFIX


17 years ago
QA Contact: lchiang → ian
verified per module owner
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core


6 years ago
blocking-b2g: --- → tef?
blocking-b2g: tef? → ---
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.