Last Comment Bug 110591 - DOMClassInfo interface shortcuts twice as fast as Components.interface.*
: DOMClassInfo interface shortcuts twice as fast as Components.interface.*
Status: VERIFIED WONTFIX
: perf
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 Linux
defect
-- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst)
: Hixie (not reading bugmail)
: Hsin-Yi Tsai [:hsinyi]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
Regressions:
Regressed by:
 
Reported: 2001-11-17 06:00 PST by Fabian Guisset
Modified: 2019-03-13 06:42 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (562 bytes, text/html)
2001-11-17 06:07 PST, Fabian Guisset
no flags Details
Added timing methods and a choice between 10k and 50k loops. (939 bytes, text/html)
2001-11-17 07:22 PST, Fabian Guisset
no flags Details

Description User image Fabian Guisset 2001-11-17 06:00:17 PST
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 User image Fabian Guisset 2001-11-17 06:07:05 PST
Created attachment 58214 [details]
Testcase

50000 runs. First button uses HTMLInputElement, second button uses
Components.interfaces.nsIDOMHTMLInputElement
Comment 2 User image Fabian Guisset 2001-11-17 07:22:03 PST
Created attachment 58217 [details]
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 User image Axel Hecht 2001-11-17 09:12:39 PST
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 User image Fabian Guisset 2001-11-18 03:18:28 PST
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 User image Johnny Stenback (:jst) 2001-11-19 01:25:55 PST
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 User image Fabian Guisset 2001-11-19 04:25:47 PST
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 User image Fabian Guisset 2001-12-22 03:33:29 PST
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 User image Hixie (not reading bugmail) 2002-11-05 10:37:47 PST
verified per module owner

Note You need to log in before you can comment on or make changes to this bug.