608224 - Significant Dromaeo DOM regression 26.10-27.10

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

http://graphs.mozilla.org/graph.html#tests=[[73,1,493]]&sel=1286079177,1288163700
http://graphs.mozilla.org/graph.html#tests=[[73,1,419]]&sel=1287572481,1288344515

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Seems like the regression happened *before* Bug 607222.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Based on tbpl, it was the Tracemonkey merge

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  The regression bot didn't catch this?  :(

Comment 4

[Chris AtLee [:catlee]]

http://groups.google.com/group/mozilla.dev.tree-management/msg/ebc9772daa6d7d89

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.... ;)

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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....

Comment 7

[Chris AtLee [:catlee]]

(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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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)...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Chris, to be clear, it's not your fault the gateway seems to be broken.  That's why I cced gerv.  ;)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Er, the link in comment 5 should have been http://dromaeo.com/?id=121148,121147,121149

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Attempted replica of the Dromaeo test for expandos

This does not seem to show the large slowdown if I disable tracejit.  So something weird is going on somewhere (interaction with the harness?).

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking on understanding if this is our test harness, or an actual regression, and if so, one that we particularly care about.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.

Comment 14

[Chris AtLee [:catlee]]

(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?

Comment 15

[Gervase Markham [:gerv]]

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

Comment 16

[Tom S [:evilpie]]

I doubt this is still relevant.