Jupyter Lab is the next generation interface for the Jupyter notebook, and it is very slow in Firefox. To reproduce: 1. `pip install jupyterlab==0.30.6` 2. `wget https://gist.githubusercontent.com/jorisvandenbossche/eb0eaf2e66d43abe144a7f414db6246e/raw/3804e918e6aa15d0ef0c6861e49ca5dc0462624d/pandas_API_groupby-agg.ipynb` 3. `jupyter lab` 4. Open the `pandas_API_groupby-agg.ipynb` notebook in the lab interface 5. Wait for many seconds for it to load (I am personally using Firefox Nightly on Ubuntu 16.04, but this should be reproducible across all versions of Firefox and most platforms). This is a known problem on the Jupyter side (see https://github.com/jupyterlab/jupytelab/issues/1639) that the Jupyter Lab developer are actively working on resolving, but I wonder whether this reveals some other performance problem with Firefox as well. Feel free to close if it isn't! I have a profile at https://perfht.ml/2AA3Db3, but this should be pretty easy to reproduce.

There is a profile in the first comment.

Hey dholbert, this looks like mostly layout (also see https://github.com/jupyterlab/jupyterlab/issues/1639)... and apparently, even though Chrome is also consto-flushing, we're doing it more slowly. Anything actionable here?

FWIW, I see some flexbox reflowing in the profile. Should this depend on other flexbox bugs?

Yup, this looks likely like a version of bug 1377253.

[qf triage: to the extent that there's anything beyond what's covered in bug 1377253 here, I think this is a qf:p3.]

I've closed out bug 1377253, but I confirmed that this bug here is still slow in Nightly (using the commands from comment 0). Profile (starting with me double-clicking "pandas_API_groupby-..." in the jupyter UI): https://perfht.ml/2zPjzTP As you can see there, we're spinning our wheels for 16-17 seconds. In contrast, Chrome only churns for ~2 seconds.

The "marker table" view shows many many script-triggered reflows (many from .scrollTop for example), a good number of which are in the 20ms-60ms range. There's likely some over-invalidation going on in those reflows & making us redo layout that we've already done.

I poked at this in GDB/rr a bit, but haven't made much progress. I learned that: - the tentative patches on bug 1503660 and bug 1504877 don't help. (Logging does suggest that we're triggering the perf issues that those bugs are meant to address, but that's apparently not the dominant perf issue.) - The slowdown is roughly because Jupyter's JS is making various layout-influencing changes to set up the page (e.g. search the profile calltree for appendChild, set_width / set_minWidth / set_borderBottom), and then flushing layout via calling .offsetTop. They'd get much better perf if they could batch their layout updates vs. offsetTop calls. That's not to say we couldn't be doing better -- but it's somewhat edge-casey, I think. At the moment, I'm not sure I can make easy progress here & I suspect this setup (rapid style changes + offsetTop flushes) is an anti-pattern that's hopefully not too common. So, I'm going to take a look at some other related flex bugs for the moment and hopefully circle back to this before long. (Also worth noting: the jupyterlab folks say they've made some improvements on this on their end, per https://github.com/jupyterlab/jupyterlab/issues/1639#issuecomment-373548445 , so it might be that their up-to-date version doesn't trigger this as badly anymore.)

(In reply to Daniel Holbert [:dholbert] from comment #8) > - the tentative patches on bug 1503660 and bug 1504877 don't help. FWIW, bug 1159042 doesn't help here either (I profiled this with that bug's patches on a clean tree, and on a tree with those ^^ two other bugs' hypothetical optimizations, and I'm still getting the same ~23+ second load time for this "notebook").