Closed Bug 601109 Opened 14 years ago Closed 14 years ago

Dromaeo (CSS) / jslib regressions on Windows due to JM: Make FrameState work for large, linear scripts

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: sayrer, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #591836 +++

Regression :( Dromaeo (CSS) decrease 4.26% on Win7 TraceMonkey
--------------------------------------------------------------
    Previous: avg 2000.221 stddev 37.191 of 30 runs up to revision b079aae53212
    New     : avg 1914.966 stddev 8.402 of 5 runs since revision 3e7fbdbd0b2f
    Change  : -85.255 (4.26% / z=2.292)
    Graph   : http://mzl.la/bKnRvY

Changeset range: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=b079aae53212&tochange=3e7fbdbd0b2f

Changesets:
  * http://hg.mozilla.org/tracemonkey/rev/1bbc0fc10747
    : David Anderson <danderson@mozilla.com> - Optimize FrameState for large linear scripts (bug 591836, r=dmandelin).
* * *
Remove FrameState::base (bug 591836 part 1, r=dmandelin).
* * *
New register pinning invariants (bug 591836 part 2, r=dmandelin).
* * *
Remove FrameState::tosFe() (bug 591836 part 3, r=dmandelin).
* * *
New copy order invariant (bug 591836 part 4, r=dmandelin).
* * *
Optimize immutable frame syncing (bug 591836 part 5, r=dmandelin).
* * *
Optimize frame merging (bug 591836 part 6, r=dmandelin).
* * *
Optimize copying frame entries (bug 591836 part 7, r=dmandelin).
* * *
Optimize mutable frame syncing (bug 591836 part 8, r=dmandelin).
* * *
Optimize syncing in try blocks (bug 591836 part 9, r=dmandelin).
    : http://bugzilla.mozilla.org/show_bug.cgi?id=591836

  * http://hg.mozilla.org/tracemonkey/rev/0ff917ab21e4
    : Mike Shaver <shaver@mozilla.org> - bug 591836: split JS out of libxul to work around VS2005 PGO compiler crash. r=khuey a=sayrer
    : http://bugzilla.mozilla.org/show_bug.cgi?id=591836

  * http://hg.mozilla.org/tracemonkey/rev/3e7fbdbd0b2f
    : Robert Sayre <sayrer@gmail.com> - Remove useless comment.

Bugs:
  * http://bugzilla.mozilla.org/show_bug.cgi?id=591836 - JM: Make FrameState work for large, linear scripts
No longer blocks: 591631, 592973, 592976, 598839, 596837, 597378, 600373
No longer depends on: 600419, 591836, 598663, 598696, 600493
blocking2.0: beta7+ → betaN+
At the moment, I suspect this regression occurred because we had to split out libjs.dll from libxul, and we lost some PGO goodness as a result. Mac and Linux did not regress.
(In reply to comment #1)
> At the moment, I suspect this regression occurred because we had to split out
> libjs.dll from libxul, and we lost some PGO goodness as a result. Mac and Linux
> did not regress.

Did we see a corresponding increase when we folded js into libxul?  I don't remember that being the case.
(In reply to comment #2)
> (In reply to comment #1)
> > At the moment, I suspect this regression occurred because we had to split out
> > libjs.dll from libxul, and we lost some PGO goodness as a result. Mac and Linux
> > did not regress.
> 
> Did we see a corresponding increase when we folded js into libxul?  I don't
> remember that being the case.

I didn't see any happy talos emails, but I didn't look too hard and might've missed them.
There might not have been a corresponding single bump; given the vagaries of PGO, the perf we're losing now might well have been part of N other wins we've taken since.
(In reply to comment #1)
> At the moment, I suspect this regression occurred because we had to split out
> libjs.dll from libxul, and we lost some PGO goodness as a result. Mac and Linux
> did not regress.

What do we want to do with this next? Do we try backing out that patch and seeing if the numbers go up? Chalk it up to libjs vs. libxul and close?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.