Nightly Graphics performance 26-31% of Nightly Safari and Chrome in Molecular Dynamics Simulation




7 years ago
6 years ago


(Reporter: stephen.bannasch, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [in-the-wild] [external-report], URL)



7 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Steps to reproduce:

Opened this page in Chrome Canary, Safari Nightly and Firefox Nightly:

Scrolled down to bottom, opened Benchmarks section and clicked "Run Benchmarks" button four times.

The performance benchmarks produce data for the graphics only, model only, and graphics and model combined. This is done without allowing the browser to repaint.

I copied all the data produced to this public Google Spreadsheet:

JavaScript Molecular Dynamics: Nightly Performance Comparison

Actual results:

Firefox Nightly performance running the model and graphics together for 100 model steps is 50% of Chrome Canary and 44% of Safari Nightly.

This performance issue is entirely caused by poor performance rendering the view since Firefox Nightly is 8% faster than Chrome Canary and 5% faster than Safari Nightly when benchmarking just the model performance.

Firefox Nightly runs the graphics benchmark 31% as fast as Chrome Canary and 26% as fast as Safari Nightly.

Expected results:

Firefox performance should be closer to the other two browsers.

The view code uses D3.js and SVG and is located here:

The code being run by the benchmarks is here:

And uses this benchmark library:

The relative slowdown in performance measured by the benchmarks is similar to the actual performance difference when running the application in the different browsers.

FYI: a related performance report on Slow model performance in Firefox was resolved:


7 years ago
Keywords: perf
Thanks for reporting this.
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Er... doesn't comment 0 explicitly say the problem is in the graphics part not the JS part?

Stephen, what operations exactly is the "Just Graphics" part measuring?
Assignee: general → nobody
Component: JavaScript Engine → Graphics

Comment 3

7 years ago
The graphics-only benchmark is defined here:

... and measures the time to run the update_drawable_positions method 100 times in the MolecularContainer view here:

The work involves reading model state from arrays and objects and creating and manipulating SVG.

The slowdown measured in the benchmark compared to Chrome and Safari is similar to the actual performance difference just running the model in the browser.
Thanks.  Chances are, this is gated on SVG perf, but needs a profile..
Component: Graphics → SVG

Comment 6

6 years ago
've just taken performance measurements from nightly versions of Firefox, Chrome, and Safari all running on the same 2010 Macbook Pro and shared the results here:

Looking just at column 9: model (steps/s) [which is column J in the spreadsheet) Firefox model-only performance is just a bit slower than Chrome for the first (2-oil-and-water-shake.json) and third (benchmarks/7-plasticforces.json) models -- while only 60% of the speed of Chrome on the second model: benchmarks/5-100-atoms.json.

From the "About" box for benchmarks/5-100-atoms.json:

  This model has 100 charged atoms, this means that the modeling engine spends proportionally
  more time calculating pairwise forces for the long-range Coulomb forces than in some of the
  other models. Since there are no bonds and no display of VDW lines the view is less computationally
  intensive than other benchmarks.

If you are interested I can show the different code paths the modeling engine takes when more of the long-range pairwise forces are included in the calculations.

Looking at performance in general combine the engine and view Firefox performance ranges from 25-50% as fast as Chrome.

Earlier the graphics performance of FF was much slower but in these latest tests (FF nightly AND improvements in our code) FF view performance is comparable to Chrome ... so I'm marking this issue as resolved ...

But,  I don't know what to make of the poor performance when running the model+graphics test or the fps test ???

See discussion continuing in this bug report:
Last Resolved: 6 years ago
Resolution: --- → INVALID


6 years ago
Whiteboard: [in-the-wild] [external-report]
You need to log in before you can comment on or make changes to this bug.