jiebi/CodeConvo huggingface dataset:
<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.62.3 (Universal) Jupyter Extension version (available under the Extensions sidebar): v2021.10. Python Extension version (available under the Extensions sidebar): v2021.11. OS (Windows Linux distro) and version: Mac Python and/or Anaconda version: 3.7.12 Type of virtual environment used (N/A ...): conda Jupyter server running: Remote I expect code cells to begin executing immediately and (for simple code snippets) to finish executing immediately (e.g. print('hello')) Once the jupyter notebook starts to contain a non-trivial amount of stuff, I start to observe the following behaviors: (1) code cells that contain simple tasks (e.g. ) start taking several seconds or more to complete, (2) it may take several seconds or even minutes for vscode to even visually show that it will start executing a code cell, and (3) in severe cases, the whole vscode editor will become unresponsive and I will need to force shut it down. Below is code for a jupyter notebook that contains a minimal example. The problems start to appear once you've cycled through the code cells 2 or 3 times. I think one of the main contributing factors to this issue are just notebooks that have a lot of "stuff" in them. To demonstrate that, the last code block prints 50 scatter plots as pngs, which the native jupyter lab server over the browser handles just fine... but vscode seems to have issues. Moreover, in this simple example I have observed instances where it starts to take a while to save the notebook and the editor may even become unresponsive. Other things to note: I am running this jupyter notebook on an AWS EC2 instance with ~90GB memory 48 CPUs (using a AWS linux ami: ). I have not yet observed these same issues when I have the kernel running on my local mac machine. <details<summaryJupyter example </summary<p</p</detailsHere is a screenshot where it takes almost 3 seconds for a simple print statement. I've seen worse in some of my code related to real projects, though. This is just what I was able to reproduce with a minimal example.
<img width="1593" alt="Screen Shot 2021-11-22 at 4 48 27 PM" src="https://user-"
Thanks for filing this issue & I'm sorry you're running into this issue, please could you try the following: Check the performance withouth any data frames in the outputs You can run most of the same cells, but not display the outputs (e.g. don't run the cells with ) I'd like to check whether the perf is a result of large outputs. If that doesn't make any difference please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Try the same thing & provide the logs from the output panel (use the command to get to the output panel)
Thanks . Not displaying large amounts of output does help. I experimented with the code a bit and here are my observations: (1) If I disable the cell with just the statement (but still outputting the figures), while it helps a little, I still see a significant slowdown. In particular, once I execute the code block that prints the figures (see below) and it is done, I try to execute the first code block again (containing the import statements), but there is a good 30-60 second delay until it will start to executing. (2) If I still create the figures but no longer display them (see below), this helps immensely with performance... there are basically no issues. (3) While still hiding the figures as in (2), but I go back to displaying and increasing the number of columns and rows of that are display to 200 (see below), then there is small decrease in performance. (4) If I do the same as (3), but take it even further by displaying 500 rows and columns of , then performance significantly degrades (see the screenshot). Once it was done displaying , it took ~19 seconds for a print statement, ~35 seconds to make the figures (normally takes a ~3-5 seconds), and it took over a minute to execute that last empty cell (the execution time was hidden once it was done). <img width="1585" alt="Screen Shot 2021-11-23 at 10 14 06 AM" src="https://user-"
Thanks for the feedback.
Please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Run the command An editor will be opened with some text such as , please copy all of that & paste that into this issue Try simple print statements (without any data frames, and figures, lets keep it very simple) Please ensure the notebook is empty & does not contain any outputs only 1-2 cells with simple print statements. Provide the logs from the output panel (use the command to get to the output panel) Reload VS Code Repeat what you did earlier Provide the logs from the output panel (use the command to get to the output panel) Please note, I'll need two logs, one without any data frames, no plots, just print statements. The other is the one with dataframes and the like.
Here is the text for : Even if vscode totally froze up while trying to run something in jupyter, I was still always able to ssh into the server no problem. Here is the Jupyter output from just the print statements: <details<summaryLog</summary</detailsHere is the Jupyter output where I print large dataframes and plots: <details<summaryLog</summary</detailsFew other things I've observed: (1) In the second log above, I see there are some lines like in it, but I was not always able to reproduce that output. (2) Here are some additional logs that I observed while it took 15 minutes to execute a cell with a simple print statement (but it was executed after cells with the dataframes and plots): <details<summaryLog from </summary</details<details<summaryLog from </summary</details
Thanks for the logs. Transferring to VS Code due to connectivity issues with remtoe SSH
Also having this issue with jupyter over ssh, in a notebook that has a decent number of plots.
This issue happened with me also (especially when i am insider a docker container inside the remote machine)
I have the same issue, even when I freshly open a notebook with some outputs it is very slow and unresponsive. <img width="273" alt="image" src="https://user-"I have a stable connection to the server: !
Same problem, sometimes it works fine, sometimes it is unusable, stable and insider !
After discussion in sync.
Possibly add logging for every message that's only turned on if the user explicitly is told to (for debugging purposes).
experiencing similar issues when working on jupyter via ssh to an ubuntu server from an ubuntu pc
ALso had the issue where running a cell lags(or starts after some time) for jupyter notebooks when using remote SSH aws azure
Still the same problem
I also experience the same. I observed that: It happens with Jupyter notebooks, but not in the Interactive window. It does not happen if you connect to a Jupyter kernel that is not managed by VScode. It happens when your notebooks has many figures. I hope these may help diagnose the problem.
Same here..
As an additional info to what enlightened us. Jupyter execution on remote ssh machine slows down (i.e., gets stuck) when notebook size is large (64 MB). VS code executing notebook cell normally for smaller sized (ie., 1MB ) notebook
Would it be possible to share such a notebook? Is the size 64 MB with or without ouput in the notebook? If its a large file you could optionally email it to one of us (us = Microsoft maintainers of VS Code)
sorry that is confidential work for the time being.
Experiencing the same issue as well. Networking is not a problem since I connect to the notebook's machine on a local network
I've also been having this issue lately although I think it only happens in certain circumstances. I can't share the notebook I'm working with at the moment as it's private (sorry!), but it does have many matplotlib figure outputs and dataframe outputs. The notebook itself is only 3.6 MB in size. I'm running the notebook on a Linux server with Python 3.9.7, specifically I'm connecting to the machine remotely with "Connect to Host" to edit and run code on the server remotely. Latest version of VS Code and all extensions, connecting from a machine running Windows 11. It seems connecting on the same network as the machine with my Linux laptop doesn't result in any issues, and I haven't noticed any problems with running the notebook from there. However, connecting from a different network when working from home causes the same notebook to be very laggy, including lagging for 30+ seconds on simple code cells containing e.g. just a print statement.
I don't see how network speed/my connection to the server from home could be the issue (12ms ping, ~5 Mbps upload / ~50 Mbps download connections). Maybe there's something in the different OSes having different results, could also be unrelated though. I should try connecting with a Linux machine not on the same network and see if I can reproduce the results.
Same problem here, just a correction it is not dependent on the figure number or commands difficulty, will take to execute 30 to 40s, and yes with a separate instance of Jupyter Lab server (not managed by VScode). Directly connecting to Jupyterlab over ssh port forwarding order of magnitude faster. Workflow: Windows to Linux remote SSH (cluster) Another instance in the cluster used to set up JupyterLab instance Change Jupyter server to remote of the previously created instance execution super slow (even delay between starting and finishing) ~ 30 second delay followed up by ~ 40 s execution Connecting directly from Windows tunnel to JupyterLab ~ few seconds execution Note: Both the Jupyter Lab instance and the initial remote ssh share access to the file system, just different hardware. Also after changing to remote, some shenanigans happen with the vscode, unable to open files, etc, had to restart everything to make it work again.
I've had the same issue with VScode and Jupyter - notebooks becoming unresponsive after a few cells are used. The console shows continuous (every 20 seconds) reconnecting. with the level set to "trace". I can share a relevant file if it is helpful.
I've had the same slow issue with VScode and Jupyter when connecting to a remote docker container via ssh, and I've also observed that keeps producing tremendous streams
If someone can share a notebook that triggers this issue (lots of outputs, graphs with lots of data, etc?) that would be helpful, thanks
I noticed that if I switch the format from svg to png (by changing the setting ), the notebook would run smoother.
My network: Roundtrip latency: 5.520ms Up: 2898.6 Mbps Down: 3007.5 Mbps Authority: ssh-remote+** Roundtrip latency: 21.320ms Up: 25.8 Mbps Down: 385.0 Mbps A test notebook (1KB zip file), need , and to run:
Having the same exact issue and it renders the jupyter unresponsive: ! And it's still running. A temporary solution I found is to click on "Clear outputs for all cells" and more often than not it works smooth again. Only works if the cell stops executing though...
I think notebook size may be the reason.
I resolved my issue by closing the JUPYTER: VARIABLES in the terminal below Maybe in my case was an issue with the output variables inside the jupyter section ..
I resolved it by using a jupyter server running on the remote machine which was not started by VSC. I'll use that until this bug is fixed unfortunately
life saviour! "Clear outputs for all cells" worked smooth as butter (:
Happy to help. I saw in one of the other tickets this bug has a synergy with notebook size, and since clearing all outputs reduces notebook size, this might be a temporary fix until the size increases eventually and we need to do it again. I would love to see this fixed as this bug is the biggest hindrance to me day-to-day vscode experience.
Same here, this issue was driving me crazy. That's the solution indeed, I had a lot of local memory usage in my code, not sure about what was the actual issue. EDIT: it seems I spoke too early. When a cell takes very long to compute, vscode seems to "disconnect" from the kernel, and any subsequenc cell evaluation waits forever without running.
I pushed a change which should mostly fix this slowness with large outputs. I think there are more optimizations we could do. The issue comes when a save happens, and this blocks the remote extension host process for some period of time. Then a symptom of that might be that an execution appears to hang or take a long time. Would appreciate anyone trying this out in tomorrow's vscode insiders build.
If you're seeing an issue related to the variables view, that wouldn't be fixed here, however I recently pushed a different fix that may help with that, and you could try it out in insiders + the jupyter pre-release extension.
I have been experiencing these slowdowns (specifically on an AWS server) and I don't use the variables view. I definitely found that clearing cell outputs eliminates the hangs. I'm confused how this is caused by saving though, because I just found that the notebook I was working on wasn't being saved. I was doing some work tethered to my phone as I rode a bus into remote mountains. Certainly noticed that the bad connectivity meant even more waiting for things to execute than usual. Unfortunately, when I got back to stronger internet vscode was complaining it couldn't connect and was hanging when it tried to save. I figured it was fine since I saw 's comment and naively interpreted that as meaning I should feel comfortable that my notebook was getting saved each time it hung. Nope. When I finally had to reload window to get things back to working I found that all the code I wrote on the bus was no longer in the notebook (no worries, I had copied it out just in case, so no loss). I'm trying the 2023-01-13T07:49:05.588Z insiders build right now (is the "tomorrow's" build that should have the changes?). I think it is still too soon for me to be able to offer an opinion on how much of an improvement this fix might be. It is hard because the problem is erratic: sometimes cells execute immediately and sometimes it takes 20 seconds or longer.
Yeah, that version has the latest fix, you might have hit a different issue. And the issue might still have been kicked off by the notebook attempting to save. I'll leave this issue open to track namely, we still send notebook data between the processes more often than we technically have to, and I think that can be improved. Sorry about that, glad you had it saved, the intent is that the unsaved changes would have been persisted on the frontend.
I can confirm that this change is a big improvement for my use case. If those additional optimizations ever get prioritized that would be amazing and appreciated, but I'm already grateful for this improvement. Thank you!
On second thought, closing this issue, and moving other work to
I have tried the insiders version on a podman container accessed on a machine over ssh (so I do vscode remote via ssh to the machine and then I use remote containers to access the container). It does not open a terminal and seems to be spinning forever with the following error in the logs: 2023-01-27 10:40:00.790 [info] [LocalProcess0][resolveAuthority(attached-container,27)][1013ms] waiting... 2023-01-27 10:40:00.818 [error] Shell server failed: Error: stream ended with:4 but wanted:9 at u (c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at c:Usersvince.vscode-insidersextensionsms-vscode-distextension at s (c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at Socket.<anonymous(c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at (node:events:538:35) at endReadableNT (node:internal/streams/readable:1345:12) at process.processTicksAndRejections (node:internal/process/task_queues:83:21) May this be related to the recent changes or shall I seek for another bug report and eventually open a new one?
Not related to this change- you can open an issue against the Remote Containers extension, I'm not sure how to interpet that error
Hello, I have installed latest Insider's VS Code, maybe it's a bit better now, but in general issue is still there. Very slooow Jupyter Notebooks on large content. I'm using jupyter/r-notebook docker image to run on AWS EC2 instance and have 2 options to acces it: from browser on 8888 port to web version of Jupyter notebooks. It works lightning fast and responsive. over SSH to EC2 instance and then "Attach to running container" So if I compare those 2 options there is a huge difference in UI when notebook has some data and charts. For me it feels like VS Code continuously sends data to server. Even dropdown for intellisence takes few seconds to load.
It's so sad that I'm unable to use VS Code Jupyter Notebooks for my work. But if I create a brand new empty notebook in VS Code - everything works like a charm!
We have experimental saving logic for Remote SSH, it would be great if you can give this a try and see if it improves the performance on large notebooks Install latest VS Code Insiders Remote SSH into your remote machine Add to your Remote/User settings Reload the window Then test the scenarios which used to slow or block the network Thanks in advance!
The improvements are noticeable, thank you for your great work! However, the latency is still there and appears to be significant from time to time. I love this ssh-notebook function, and I believe there must be more folks like me. Hope your team can prioritize this issue. Appreciate!
Hi, I just checked VS Code Insiders 1.81.0 version with "Remote Save" feature enabled in settings. I have generated in a loop 30 charts in first cell and after this I run code in a new cell. It still hangs for a while after generating charts for the first run. If I run second cell code again, it executes immediately as expected. So we still have an issue when a lot of data (or visual data) was generated recently. I checked the same code in web UI of Jupyter - and it works fast. Anton. From: Peng Lyu Friday, June 30, 2023 12:33 AM To: microsoft/vscode bo44arov Mention Re: [microsoft/vscode] Jupyter over remote ssh sometimes becomes slow and/or unresponsive (Issue ) have experimental saving logic for Remote SSH, it would be great if you can give this a try and see if it improves the performance on large notebooks Install latest VS Code Insiders Remote SSH into your remote machine Add "notebook.experimental.remoteSave": true to your Remote/User settings Reload the window Then test the scenarios which used to slow or block the network Thanks in advance! Reply to this email directly, view it on GitHub, or unsubscribe You are receiving this because you were mentioned.Message ID:
Chinese (Simplified) : <img width="321" alt="image" src="https://user-"English : <img width="272" alt="image" src="https://user-""Create Manual Folding Ranges from Selection" is not in Command Palette when use Chinese (Simplified) VSCode Version: 1.71.0 (both macOS & Win10) Chinese (Simplified) Version: 1.71.
Thank you for your feedback. We are currently reviewing it (reference ).
Could you please assist here? Thank you.
The problem is this label: should accept an  but it only accepts a string. deeper: and deeper:
The workaround is to use  to find this item.
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --This problem occurs on the vscode server. Here is the version information. Version: 1.91.1 Commit: Date: 2024-07-09T22:08:03.155Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 Steps to Reproduce: I'm not sure if this issue has been fixed yet. I reproduced the problem on the vscode client, installing the plugin, and connecting to the remote. My system is Windows OS. ! I'm trying to reproduce this problem. On a windows server, the fsPath is spliced by . When verifying, The authority of the URI is localhost:8080. Therefore, the verification fails and an error is reported in the search box. I took a look at the code and changed fsPath to path in line 257 of the file. The query works fine. But fsPath is still concatenated with . I would like to ask, what is the difference between fsPath and path? When does fsPath use to concatenate. Looking forward to your answer. !
I found the reproduction scenario of problem three. This is the IDE version information.
Version: 1.91.1 (user setup) Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: the vscode and remote-ssh extension to a Remote Server any project a file that is not in the current workspace the search view and select Search only in open Editors button Keyword !
Can you file separate issues for these three? Or at least a separate one for the first two? I'm not sure if I understand what you're saying here, can you rephrase? What OS is your remote? I'm assuming it's windows if the path uses path separators?
Okay, I've submitted questions one and two separately. This means that you open a file in the editing area that is not in the working area. You can refer to the file opened using the Open File... menu in the gif image. My remote is linux.
Also, please confirm if this issue is also present on vscode server, I am seeing this issue on vscode server as well
Hmm, yes, I can reproduce this issue.
Testing Issue Type: <bBug</bextension search box, type Bug start showing up instead ! VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-30T05:11:25.700Z) OS version: Darwin x64 17.7.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
what should we do in this case? We aren't able to change how these match. We could disable fuzzy finding entirely