Closed
Bug 1423189
Opened 6 years ago
Closed 6 years ago
DevTools React 16 DAMP without debugger tests
Categories
(DevTools :: Framework, defect, P3)
DevTools
Framework
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: miker, Assigned: miker)
Details
Attachments
(1 file, 1 obsolete file)
59 bytes,
text/x-review-board-request
|
Details |
Obviously we would prefer to run this with the debugger but code that was written in order to prepare the debugger for React 16 has still not been landed on Mozilla Central. For the moment I have disabled all of the debugger tests in the hope this will give us some interesting DAMP results or at the least some useful errors.
Assignee | ||
Updated•6 years ago
|
Has STR: --- → irrelevant
Assignee | ||
Updated•6 years ago
|
Summary: DevTools React 16 DAMP without debugger → DevTools React 16 DAMP without debugger tests
Comment hidden (mozreview-request) |
Comment 2•6 years ago
|
||
Mike, you would have to comment these 4 lines to disable debugger tests on DAMP: https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/devtools/addon/content/damp.html#17,25,49,57
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Updated•6 years ago
|
Attachment #8934524 -
Attachment is obsolete: true
Assignee | ||
Comment 8•6 years ago
|
||
The results are fairly consistent 2% - 5% across the board improvement across all operating systems. The biggest improvements are: Linux 64 Average 6.38% improvement - complicated.memory.reload 2.81% regression - complicated.netmonitor.close 30.85% improvement - complicated.webconsole.reload 3.73% regression - console.bulklog 9.45% improvement - console.objectexpand 19.86% improvement - console.openwithcache.open 7.66% improvement OS 10.10 Average 4.77% improvement - complicated.netmonitor.close 28.41% improvement - complicated.takeCensus 22.57% regression - console.bulklog 9.73% improvement - console.objectexpand 20.5% improvement - simple.performance.reload 23.25% improvement - simple.performance.close 12.89% regression Windows 10 Average 7.08% improvement - complicated.netmonitor.close 29.8% improvement - console.bulklog 9.52% improvement - console.objectexpand 20.1% improvement - simple.performance.reload 23.24% improvement - simple.performance.close 12.89% regression Windows 7 Average 6.96% improvement - complicated.netmonitor.close 27.75% improvement - console.bulklog 7.74% improvement - console.objectexpand 19.89% improvement - simple.memory.open 4.7% improvement - simple.performance.open 5.89% improvement - simple.performance.reload 30.77% improvement - simple.performance.close 31.3% regression
Comment 9•6 years ago
|
||
By using a custom "base" build, and also by running more "new" runs (not just one as you did. Remember to push with --rebuild-talos 5), I get slightly different results: complicated.netmonitor.close -31% simple.netmonitor.close -7% console.objectexpanded.close -6% simple.performance.close -5% Can be ignored, close tests are still a flaky complicated.memory.reload +4% complicated.webconsole.reload +2% simple.netmonitor.reload +4% Updating tools on reload is slightly slower, don't really get why. simple.netmonitor.reload should involve very few react, if any. complicated.saveHeapSnapshot -3% console.bulklog -9% console.objectexpand -19% Looks like these two tests are involving react a lot? Do you have anything really specific to console/reps or you only converted as-is to React 16? complicated.netmonitor.requestsFinished -2% netmonitor involves a lot fo react, so it makes sense to see a win here. that was the win I was expecting to see. inspector.mutations +2% DAMP report a medium confidance, so I wouldn't worry about this. complicated.performance.open -4% console.openwithcache.open -7% complicated.webconsole.open -3% simple.inspector.open -3% simple.netmonitor.open -3% simple.performance.open -4% simple.webconsole.open -5% Looks like overall, the panels are faster to load. Are the new react modules significantly smaller? If they are, that very easily justify a faster open time for all tools! https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=try&originalRevision=2b667a68c6ef4a781b5f04675c96fd0a7e705074&newProject=try&newRevision=69a3f2ad34e7b9f74e7219da8c6b0c1df717a019&originalSignature=edaec66500db21d37602c99daa61ac983f21a6ac&newSignature=edaec66500db21d37602c99daa61ac983f21a6ac&showOnlyImportant=1&framework=1
Assignee | ||
Comment 10•6 years ago
|
||
(In reply to Alexandre Poirot [:ochameau] from comment #9) > By using a custom "base" build, and also by running more "new" runs (not > just one as you did. Remember to push with --rebuild-talos 5), I get > slightly different results: I never considered rebuilding a bunch of times but that would make sense. > complicated.netmonitor.close -31% > simple.netmonitor.close -7% > console.objectexpanded.close -6% > simple.performance.close -5% > Can be ignored, close tests are still a flaky > > complicated.memory.reload +4% > complicated.webconsole.reload +2% > simple.netmonitor.reload +4% > Updating tools on reload is slightly slower, don't really get why. > simple.netmonitor.reload should involve very few react, if any. > > complicated.saveHeapSnapshot -3% > > console.bulklog -9% > console.objectexpand -19% > Looks like these two tests are involving react a lot? > Do you have anything really specific to console/reps or you only > converted as-is to React 16? > I converted reps to use ES6 classes, a prop-types import instead of React.PropTypes and a dom-factories import instead of React.DOM to be ready for React 16 but they never made their way from the GitHub repo to m-c. Because of this I generated a new reps.js file whilst I am waiting for the official version to land. The official version should be the same as my temporary version. > complicated.netmonitor.requestsFinished -2% > netmonitor involves a lot fo react, so it makes sense to see a win here. > that was the win I was expecting to see. > 2% seems very small but I guess in reality it is a reasonably big win. > inspector.mutations +2% > DAMP report a medium confidance, so I wouldn't worry about this. > > complicated.performance.open -4% > console.openwithcache.open -7% > complicated.webconsole.open -3% > simple.inspector.open -3% > simple.netmonitor.open -3% > simple.performance.open -4% > simple.webconsole.open -5% > Looks like overall, the panels are faster to load. > Are the new react modules significantly smaller? > If they are, that very easily justify a faster open time for all tools! > It is more complex than that. The main React modules are react, react-dom and react-dom-server. - React.PropTypes has been moved to react-prop-types - React.DOM has been moved to react-dom-factories - React.TestUtils has been moved to react-dom-test-utils - Reach.Perf no longer exists So in reality almost nothing has been removed but the packages have been redistributed. The React guys have also stopped using Webpack and started to use https://github.com/rollup/rollup instead due to it creating packages with faster load times. The most significant change is React Fibre, which is a complete rewrite of the React Reconciler. The Reconciler calculates the differences between virtual DOMs and adds the changes. In a nutshell, React Fibre uses requestIdleCallback to process batches of nodes on the Render Tree. This stops it from blocking the main process and allows it to skip some renders if more are incoming. Of course, the next step is to make this process async and we should see **much** bigger gains there.
Assignee | ||
Updated•6 years ago
|
Status: ASSIGNED → RESOLVED
Has Regression Range: --- → irrelevant
Closed: 6 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•