Closed Bug 608224 Opened 14 years ago Closed 11 years ago

Significant Dromaeo DOM regression 26.10-27.10

Categories

(Core :: JavaScript Engine, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED INVALID
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: smaug, Unassigned)

References

Details

Attachments

(1 file)

Seems like the regression happened *before* Bug 607222.
Based on tbpl, it was the Tracemonkey merge
Assignee: nobody → general
Component: General → JavaScript Engine
QA Contact: general → general
blocking2.0: --- → ?
Hmm.  The regression bot didn't catch this?  :(
The urls in comment 0 hang the browser, so I dunno if what I'm seeing accounts for the entire regression.  But what I see is that disabling jitprofiling gives me a 9% overall speedup on the dromaeo "dom" tests (dom-attr, dom-modify, dom-query, dom-travers) on the live site; I have no idea what tbox actually calls "dom" here.

You can see the results at http://dromaeo.com/?id=121148,121147 (profiling on on the left, profiling off in the middle, tracejit off entirely on the right as a comparison).

The get/set element.id tests under "DOM Attributes" are 30% slower with profiling on (and times match the methodjit-only test), the "get expando property off a node" is 50% slower with profiling off (again matching methodjit-only).  The "set expando property" test is 20% slower.  Not tracing those loops is expected given the profiling code, since they just do property access.  But we need to either weight property access towards the tracer (only for DOM objects?) or make JM as fast as tracer on it or something.  Is getting a random property off a non-DOM object also 50% slower in JM?

The DOM Modification tests are about the same before and after.

Same with DOM Query.

Under DOM Travesal, the tests that exercise property access, so .nextSibling and .previousSibling, are 30% slower with profiling on, and match methodjit.  The .childNodes test is 15% slower.  This seems to be the same issue as the DOM Attributes tests. 

For what it's worth, just the regressions I list above (four tests 30%, on test 50%, one 20%, one 15%) give an overall regression on this test set of 8%, which is close enough to the regression I see given the approximate nature of those numbers.

I just hope I'm seeing the same thing tbox is seeing.... ;)
Blocks: 580468
> http://groups.google.com/group/mozilla.dev.tree-management/msg/ebc9772daa6d7d89

Very interesting.  As far as my Thunderbird knows, the mozilla.dev.tree-management newsgroup does not have this message.  

It also doesn't know about these:

http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/395b3155c6d570e0#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/165266c3ab775c74#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/d25862bd4f919d75#

(it can see some of the _replies_ to some of these messages, but not the messages themselves).  I wonder who else is not getting these messages....
(In reply to comment #6)
> > http://groups.google.com/group/mozilla.dev.tree-management/msg/ebc9772daa6d7d89
> 
> Very interesting.  As far as my Thunderbird knows, the
> mozilla.dev.tree-management newsgroup does not have this message.  
> 
> It also doesn't know about these:
> 
> http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/395b3155c6d570e0#
> http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/165266c3ab775c74#
> http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/d25862bd4f919d75#
> 
> (it can see some of the _replies_ to some of these messages, but not the
> messages themselves).  I wonder who else is not getting these messages....

You're the 2nd person I've heard of not getting these messages through nntp.  Personally, I subscribe to the mailing list, so have been getting them.
Well, clearly the people who would actually file bugs based on the messages are not getting them (note that Olli's bug report is based on the graphs, not on the message, and he had to go re-figure-out the push range)...
Chris, to be clear, it's not your fault the gateway seems to be broken.  That's why I cced gerv.  ;)
This does not seem to show the large slowdown if I disable tracejit.  So something weird is going on somewhere (interaction with the harness?).
Blocking on understanding if this is our test harness, or an actual regression, and if so, one that we particularly care about.
blocking2.0: ? → betaN+
To be clear, the actual dromaeo site that actual reporters and users will be testing what we ship on is showing a definite and noticeable regression.

The only unclear thing is what the impact is on real-life code.
(In reply to comment #9)
> Chris, to be clear, it's not your fault the gateway seems to be broken.  That's
> why I cced gerv.  ;)

apparently giganews doesn't accept base64 encoded messages?
catlee: That may be true; but how come most of them get through, and this one didn't? Is it because it's hit some sort of size threshold and so gets encoded, or something?

This issue with missing messages is now bug 608287; please continue debugging there.

Gerv
blocking2.0: betaN+ → -
status2.0: --- → wanted
I doubt this is still relevant.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: