issue_comments

Closing as upstream issue

xref: https://github.com/jupyterlab/jupyterlab/issues/8971

Here are some profiling results on my laptop (MacOS 11.2, MacBook Pro 13-inch, 2019).

versions:

chrome: 91.0.4472.114 jupyterlab: 3.0.14 xarray: (master) pandas: 1.2.2

The results below only show the refresh of the ouput cell when I re-execute it (I used the screenshots in chrome's web developer tools to manually set the time span of interest on the profiling timeline).

I've also measured the rendering of a very basic pandas dataframe using

python import xarray as xr import numpy as np import pandas as pd data = np.random.rand(4) a = xr.DataArray(data, coords=[np.arange(4)], dims=['x']) df = pd.DataFrame({'col': data})

pandas / no additional cell

pandas / many empty cells

xarray / no additional cell

xarray / many empty cells

So it seems to me that it's more a Jupyter notebook issue. The decrease in performance (rendering time) scales pretty much the same for pandas and xarray reprs.

Maybe a Jupyter issue and not related to libraries in use?

I see. Indeed, I didn't see any significant difference among branches.

I may be able later today when I am back to my main computer

I tried but I think maybe better to wait for your update.

Maybe can we measure the first-loading time? I observe the first-loading time is very long... (movie)

The only way I was able to see it was to use the Web Dev tools that come as part of Firefox or Chrome.

Can you tell me more about this? I'll try to reproduce and measure the performance.

https://user-images.githubusercontent.com/6815844/124090964-4e601e80-da90-11eb-8333-7c2a25a8f33d.mp4

did you try if there are differences when running an individual cell, not just when loading the page the first time?

I tried to measure the performance by running all the cells as shown in the image but I could not find any significant difference.

However, I'm not very confident if this actually measures the css performance.

@SimonHeybrock, do you have any suggestions how to measure the peformance?

I am trying to measure the performance of master, this PR and mine (which fixes this PR to be compatible with dark mode) but couldn't see any big difference in my environment.

What I did in this experiment is to make a notebook with hundreds of empty cells with xarray under these branches. Refreshed the browser to render the htmls. Number of cells are the same in all these experiments, but only the xarray branches (and produced html) are different.

Maybe we may need more cells? Any advice would be appreciated.

https://user-images.githubusercontent.com/6815844/124035536-9ef75d80-da37-11eb-9c78-a9c76d16da1a.mp4

movie top left: this branch top right: mine bottom left: master

Marked this as "plan to merge" — please comment if you think that's a bad tradeoff between performance and dark mode.

It would be a shame to lose the benefits of this.

• It seems like between us we're not going to figure out the dark mode issue. Are there any CSS people out there who could offer guidance?
• Assuming not, should we merge this knowing dark mode* will look worse? I wrote above we should fix it, but I had thought that was a few extra lines, rather than intractable. I would probably vote to prioritize performance above aesthetics.

(* Did you know that research suggests we're either the same or slightly better at reading light mode?? Is dark mode LARPing?)

This

https://github.com/fujiisoup/xarray/blob/6225f158626e75977a0a944fbc09c50769884e35/xarray/static/css/style.css#L5-L29

looks working with a darkmode, but I'm not sure if this solves the original problem.

It looks to me that defining custom properties in html[theme=dark] may cause the same problem.

Confirmed that this also breaks the darkmode also in google colab.

@fujiisoup added the vscode dark mode support, maybe he has ideas.

I did it in #4036 but this was actually a workaround and should be improved by an expert. I'll take a look, but with little hope to fix.

@fujiisoup added the vscode dark mode support, maybe he has ideas.

I am out of comfort zone with CSS & JS — but does Toggle Developer Tools in VSCode give you access to the DOM?

Thanks a lot @andersy005

That looks concerning enough we should fix before merging:

@SimonHeybrock how would you feel about giving the vscode-dark a swing too?

Here's the same notebook (using master branch)

Here are two screenshots for two themes (using this PR):

• Night Owl

• GitHub Theme

I don't have VS code so I can't try, but looking at the CSS I feel that this would actually break the colors there, since I moved the general settings from root into xr-wrap, below the level where the vscode-dark settings are defined. I don't know how to fix this though.

@SimonHeybrock, I am going to try this out in VS code and will report back how it goes.

@SimonHeybrock would you be able to see whether running this with vscode-dark is acceptable? We can merge with a TODO or issue assuming it doesn't make the issue worse in that environment.

Thanks for the review @jsignell !

I think the vscode-dark settings also may need to change,

Can someone try out this PR in VS Code please?

Thanks @SimonHeybrock ! Tagging @jsignell & @benbovy as the experts!