Closed Bug 1423189 Opened 6 years ago Closed 6 years ago

DevTools React 16 DAMP without debugger tests

Categories

(DevTools :: Framework, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: miker, Assigned: miker)

Details

Attachments

(1 file, 1 obsolete file)

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.
Has STR: --- → irrelevant
Summary: DevTools React 16 DAMP without debugger → DevTools React 16 DAMP without debugger tests
Attachment #8934524 - Attachment is obsolete: true
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
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
(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.
Status: ASSIGNED → RESOLVED
Has Regression Range: --- → irrelevant
Closed: 6 years ago
Resolution: --- → WORKSFORME
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: