Optimize IPC traffic when saving notebooks (large notebooks slow over Remote-SSH?)

[roblourens]

#138784 (comment)

[rebornix]

A few ideas from discussions with Kai and a few others:

• If we can run the serializer in web worker EH and once we have SAB support, we don't have to send buffers back and forth, which can save a lot of time. It does require the serializer to be an UI extension other than a workspace extension.
• Or, we can probably do a fast "notebookToData" by asking if the EH already has the latest notebook document
  • EH which has the serializer running, has a copy of NotebookDocument, we ask if its version id is the same as the one in the renderer, if so, serialize it and return the buffer back. If not, we go to traditional route.

[jrich100]

Any updates on this?

We have seen situations where large notebooks not only become unusable, but the rest of the UI becomes very slow.

Specifically seems to happen when using tools that embed charts and graphs as js in the cell output/metadata (ex. bokeh).

[baiguoname]

Any updates on this?

[spinicist]

I am experiencing this issue too. I accept my current Notebook is pathological (a large amount of plots), but VS Code is unusable like this. I'd be very happy with "slow"!

[rebornix]

This can be reproduced easily by remote ssh into another machine in the same local network with following code

for i in range(0,1000000):
    print(i)

When we have auto save turned on (w/ 1 second delay), it will generate upload/download at 10MB/s for several minutes. When the vm is truly remote, it means the bandwidth is fully used by the file saving and output updating.

[bpasero]

Making some progress:

• working copy - allow to override backup delay (#172345) #185958
• working copy - allow to custom save method on model (#172345) #185963
• files - allow more file operations to run in the extension host (#172345) #185988

[rebornix]

@tbenthompson is "notebook.experimental.remoteSave": true making the experience any better or you don't see any change at all?

[jrich100]

Generally, I think the experience with large notebooks has improved (though in a way that is hard to quantify)!

However, I am still able to create a scenario that feels very very slow....

1. Run a cell that creates ~50 large matplotlib plots in a loop
2. Once the above cell completes, immediately run a cell with a simple print() statement

In this scenario, the notebook hangs for over 90 seconds before executing the print() cell. Presumably, the cell execution is blocking on the notebook file saving/syncing?

[xiaoxuchn]

I have pretty much the same experience with @jrich100 . I plotted out 50 images in a for loop. It was taking extremely long time (about 1 hour) to save the output. I saw my wifi was running full speed uploading at 5Mbps. I've turned the experimental remote save settings on. It doesn't seem to help. Even after I turned auto save off, I still needed to wait that long to run the next cell. I've no idea what it was uploading.

[fratorgano]

I'm having the same problem, whenever I try to save a big notebook, even if I changed a single line of code, it takes a lot. This kills performance, especially when working with a mobile connection.
I tried the notebook.experimental.remoteSave: true setting in the non-insider version of vscode since it was also available there, but that didn't make any noticeable difference for me.
I downloaded the vscode insider version and tried it there, and it was saving much faster.

[lucashmorais]

(Still experiencing the issue in the 1.94.2 release even with "notebook.experimental.remoteSave": true)