Closed loftusa closed 7 months ago
Thank you for filling this issue and sorry you are running into these issues
I would like to get to the bottom of these issues and get you unblocked
Please could you enable logging as follows:
Jupyter->Logging
verbose
Jupyter
output panel.I have exactly the same issues. The notebooks get especially slow as they get bigger. But many of the problems already exist in an empty notebook.
Same here as @dschaub95 . Could you @DonJayamanne upload a screenshot of Jupyter output panel? I have nothing here. This issue did not present couple of versions of vscode before. It is a recent versions thing.
Okay, I found Jupyter output panel.
Here is the log @DonJayamanne . Any other information needed? I'm not sure how to command ‘Jupyter: Show Output’ to get to the logs, so I copy all of them from the Jupyter output panel. log.zip
@jhancibo @dschaub95 @loftusa Does this repro when you close the variable view Please ensure you always hide the variable view completely Let me know of the issue persists even after that
In my experience, it is entirely independent of the variable view.
If you have the Jupyter powertoys extension Please disable that as well
I don't use the powertoys extension at all. Maybe it's also important to mention that the problems with jupyter notebooks are even more severe when developing on a remote server (via ssh or Kubernetes). However, they still persist when developing locally.
@dschaub95 Please could you enable logging as follows:
Jupyter->Logging
verbose
Jupyter
output panel.please share these logs when you run into perf issues
The output is attached. As far as I could see, the output only changed when the cell started executing. The time between me trying to execute and the actual execution seems not to be logged. logs.txt
In my experience, it is entirely independent of the variable view.
Same here. And I didn't install powertoys extension.
@DonJayamanne The issue persists after close the variable view completely.
@dschaub95 @jhancibo I’m being sorry this is still unresolved Please can you try the following
Developer: Set log level
extension host
and select info
Extension host
Once again thank you for your continued patience ands support
@DonJayamanne Could you recording a video to do those instruction above? I tried and it is abstract to follow each step. For example, when I type Developer: Set log level in command palette, I see nothing pop up. If you have time to recording the video, I would be very happy to test it. Thanks.
The time between me trying to execute and the actual execution seems not to be logged.
Please send the logs from Extension Host
and Jupyter
From the ExtenisonHost
logs I'm only interested in the lines that have the text [trace] NotebookController[...] EXECUTE cells
@dschaub95 @jhancibo Please could you send these two logs From what I understand
Please let me know
ExtensionHost
logs from the time you try to run a cell.
@dschaub95 You have already confirmed that Jupyter logs do not get updated, please check the ExtensionHost
logs as well.ExtensionHost
and Jupyter
logs before you start executing cells)Please can you try the following
Developer: Set log level
extension host
and select info
Extension host
Once again thank you for your continued patience ands support
Closing this issue as its been over 4 weeks, since the information was requested. We'll be happy to reopen the issue when the requested information has been provided.
got one example and the logs are in https://github.com/microsoft/pylance-release/issues/5301 (Note that I'm not disabling all other extensions).
UPDATE: having the same issue again, but nothing in Extension Host (in info level). the pending lasted for about one minutes. I tried it again with debug level for Extension Host, the only logs (from middle of pending to after execution) are as follows. (seems unrelated?)
meanwhile, the time shown below is incorrect - the waiting time is more than one minute.
2023-12-22 14:30:10.159 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"selections":{"selections":[{"start":34,"end":35}]}}
2023-12-22 14:30:27.062 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"selections":{"selections":[{"start":35,"end":36}]}}
2023-12-22 14:30:33.206 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"selections":{"selections":[{"start":35,"end":36}]}}
2023-12-22 14:30:48.061 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"visibleRanges":{"ranges":[{"start":33,"end":36}]}}
2023-12-22 14:30:51.428 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"visibleRanges":{"ranges":[{"start":33,"end":37}]}}
2023-12-22 14:30:52.066 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"selections":{"selections":[{"start":35,"end":36}]}}
2023-12-22 14:31:30.497 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"selections":{"selections":[{"start":35,"end":36}]}}
2023-12-22 14:32:34.055 [debug] ExtHostNotebook#$acceptEditorPropertiesChanged 47805538-ec73-4099-90db-736613202be8 {"visibleRanges":{"ranges":[{"start":33,"end":36}]}}
and again, pls note that I'm not disabling other extensions during work, which is not consistent with your instruction above.
Hi, i think this issue should not be closed because it is not solved.
Or does someone have a solution?
When I run notebooks in jupyter lab in the browser everything is instant but in vscode everything runs delayed.
Not sure if this is what you're seeing, but I've noticed a regression of an old bug. I have a code cell that should run in a fraction of a second. I run it. It's stuck for about 1 minute. Then all of a sudden it runs.
Very annoying. Because of this and other, numerous bugs, I'm thinking to go back to Jupyter Notebook in a browser.
I don't know if Windows interferes the "vscode ipykernel" differently than the "kernel type" that is started by running jupyter lab.
But I noticed that on my macbook air m2 vscode restarts kernels and runs cells fast.
Perhaps there are some Windows processes like Windows Defender and proxy and vpn settings that interfere with the ipykernel when starting a kernel from vscode.
Here is an issue that describes some of these things:
https://github.com/jupyter/notebook/issues/1415
I am experiencing the same issue. A few days ago, everything was working fine but after updating to the latest version, Visual Studio Code is using almost 90% of my CPU and the Jupyter Notebook is also running slow. Previously, I could use 3-4 notebooks at a time with my current setup but now running even one notebook is not possible. On the other hand, everything is smooth in Jupyter Lab.
"I have attached the cell loading data. It has been stuck for 5 minutes now and is not running."
In my experience, jupyter notebooks performance degrades very quickly in the size of the notebook. This is especially true for plotly.express plots, and is independent of whether I am using a .ipynb file or the interactive cell views for a .py file.
Describing the experience for a .py file: when there are no plots and no LaTeX in the interactive window, everything is snappy. But if I have even just a handful of plots (or many lines of rendered LaTeX from Markdown cells), then it takes multiple seconds between when I press Shift+Enter and when the interactive window starts running the command. If I click "clear all", everything is quick again. This seems to largely depend on how many plots are in the interactive window, not how many are currently visible.
Some other observations:
@JasonGross All that is true, but the bug where it gets stuck on a cell does not depend on notebook size or plot complexity.
Is this behavior related? I sometimes see code execution hanging for multiple minutes on trying to write to the interactive window. Maybe there's a similar blocking IO writing call that is deadlocked or something in the other cases?
---------------------------------------------------------------------------
KeyboardInterrupt Traceback (most recent call last)
Cell In[161], line 12
10 weights[q_tok, max_tok, n_copies_nonmax] = (max_tok - 1) ** n_copies_nonmax * math.comb(model.cfg.n_ctx - 1, n_copies_nonmax)
11 for _, v in min_gaps_list_nosvd:
---> 12 weighted_histogram(v.flatten().detach().numpy(), weights.flatten().detach().numpy(),labels={"x":"gap", "y":"count * # sequences"}, num_bins=v.max().item()).show(RENDERER)
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/plotly/basedatatypes.py:3410, in BaseFigure.show(self, *args, **kwargs)
3377 """
3378 Show a figure using either the default renderer(s) or the renderer(s)
3379 specified by the renderer argument
(...)
3406 None
3407 """
3408 import plotly.io as pio
-> 3410 return pio.show(self, *args, **kwargs)
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/plotly/io/_renderers.py:386, in show(fig, renderer, validate, **kwargs)
383 fig_dict = validate_coerce_fig_to_dict(fig, validate)
385 # Mimetype renderers
--> 386 bundle = renderers._build_mime_bundle(fig_dict, renderers_string=renderer, **kwargs)
387 if bundle:
388 if not ipython_display:
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/plotly/io/_renderers.py:294, in RenderersConfig._build_mime_bundle(self, fig_dict, renderers_string, **kwargs)
291 if hasattr(renderer, k):
292 setattr(renderer, k, v)
--> 294 bundle.update(renderer.to_mimebundle(fig_dict))
296 return bundle
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/plotly/io/_base_renderers.py:126, in ImageRenderer.to_mimebundle(self, fig_dict)
125 def to_mimebundle(self, fig_dict):
--> 126 image_bytes = to_image(
127 fig_dict,
128 format=self.format,
129 width=self.width,
130 height=self.height,
131 scale=self.scale,
132 validate=False,
133 engine=self.engine,
134 )
136 if self.b64_encode:
137 image_str = base64.b64encode(image_bytes).decode("utf8")
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/plotly/io/_kaleido.py:143, in to_image(fig, format, width, height, scale, validate, engine)
140 # Validate figure
141 # ---------------
142 fig_dict = validate_coerce_fig_to_dict(fig, validate)
--> 143 img_bytes = scope.transform(
144 fig_dict, format=format, width=width, height=height, scale=scale
145 )
147 return img_bytes
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/kaleido/scopes/plotly.py:153, in PlotlyScope.transform(self, figure, format, width, height, scale)
142 raise ValueError(
143 "Invalid format '{original_format}'.\n"
144 " Supported formats: {supported_formats_str}"
(...)
148 )
149 )
151 # Transform in using _perform_transform rather than superclass so we can access the full
152 # response dict, including error codes.
--> 153 response = self._perform_transform(
154 figure, format=format, width=width, height=height, scale=scale
155 )
157 # Check for export error, later can customize error messages for plotly Python users
158 code = response.get("code", 0)
File ~/guarantees-based-mechanistic-interpretability/.venv/lib/python3.10/site-packages/kaleido/scopes/base.py:305, in BaseScope._perform_transform(self, data, **kwargs)
302 self._std_error = io.BytesIO()
304 # Write and flush spec
--> 305 self._proc.stdin.write(export_spec)
306 self._proc.stdin.write("\n".encode('utf-8'))
307 self._proc.stdin.flush()
KeyboardInterrupt:
Is this behavior related? I sometimes see code execution hanging for multiple minutes on trying to write to the interactive
This does not seem to be related to VS Code or the like. Based on the error message, its a stack trace from Python code, ie its the python code that is hanging. I.e. python code you are running is hanging the kernel.
@FayzulSaimun
A few days ago, everything was working fine but after updating to the latest version, Visual Studio Code is using almost 90% of my CPU and the Jupyter Notebook is also running slow. Previously, I could use 3-4
Most likely unrelated to the Jupyter extension. Please can you follow the notes here and file an issue withe the relevant logs, to help us identify the bottleneck https://github.com/microsoft/vscode/wiki/Performance-Issues
Is this behavior related? I sometimes see code execution hanging for multiple minutes on trying to write to the interactive
This does not seem to be related to VS Code or the like. Based on the error message, its a stack trace from Python code, ie its the python code that is hanging. I.e. python code you are running is hanging the kernel.
@DonJayamanne I don't see how this could possibly be unrelated to VS Code. When I run code on the command line, it executes in a couple of seconds and dumps {'image/png': <base64-encoded png>}
to stdout. When I execute in a cell in VS Code, it hangs on a stdin.write for over 5 minutes. This indicates to me that VS Code is failing to read from its buffers in a timely manner, resulting in hanging on things that are trying to print to the interactive window.
@suiluj
Here is an issue that describes some of these things: https://github.com/jupyter/notebook/issues/1415
Looks like this indicates that some of these issues could be caused by VPN issues, But i suspect thats not what you are running into or is it?
When I run notebooks in jupyter lab in the browser everything is instant but in vscode everything runs delayed.
Please can you share a very simple sample of this issue
Jupyter: Show Output
to get to the logs)print("Hello World")
statementPlease could you enable logging as follows:
Jupyter->Logging
verbose
Jupyter
output panel.This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
In my experience, jupyter notebooks performance degrades very quickly in the size of the notebook. This is especially true for plotly.express plots, and is independent of whether I am using a .ipynb file or the interactive cell views for a .py file.
Describing the experience for a .py file: when there are no plots and no LaTeX in the interactive window, everything is snappy. But if I have even just a handful of plots (or many lines of rendered LaTeX from Markdown cells), then it takes multiple seconds between when I press Shift+Enter and when the interactive window starts running the command. If I click "clear all", everything is quick again. This seems to largely depend on how many plots are in the interactive window, not how many are currently visible.
Some other observations:
- Making fancy interactive .js plots slows vscode way more than making png plots
- When my notebooks contain many interactive plotly.express plots, the .ipynb files saved from vscode can be ~10x larger (100+MB rather than 10MB) than equivalent notebooks saved from Google Colab
I'm experiencing the same issue and I have exactly the same observation as @JasonGross .... which pushed me to switch to web-based version...
@rebornix @amunger /cc
Hi,
Just adding to this. I have been having the issue shown below when hovering over Plotly graphs created with large data, which does not happen running normal Jupyter notebook on the web. Hope it helps.
Best
I'm having the exact same issue as all here! I don't know how this could not be related to VS Code since it is happening to all of us when using the editor.
Experiencing the same issues. I have disabled all extensions except for python, Jupyter and the Jupyter renderer. I also uninstalled and reinstalled Vscode and conda. I have included the logs from notebook startup followed by a run all, and then followed by another run all. This issue does not occur when running the same notebooks in Jupyterlab Desktop, Jupyterlab, or Pycharm. Note, similar behavior was experienced in Jupyterlab that was fixed in version 4.0 (see this jupyterlab issue). I can confirm that this notebook specifically experienced the same issue when run in jupyterlab versions less than 4.0 and the update fixed it. Perhaps whatever they changed in their rendering may help here.
macOS 14.3.1
M1 Max CPU/GPU with 64 GB ram
VsCode info:
Python extension version v2024.2.1
Jupyter extension version v2024.2.0
Jupyter renderer version v2024.2.0
Python 3.12
Problem has persisted through various versions for all of the above and is reproducible with a barebones evironment
Issue is reoccurring throughout multiple longer notebooks even with no external data loaded and fewer cells than this
Same issues occur when cells are manually run as opposed to using run all
It is unacceptable that Jupyter notebook rendering is so subpar in Vscode given that notebooks are one of the most commonly used tools for data analysis and prototyping. I have no choice but to switch to PyCharm, which I would prefer not to do.
Experiencing same issue - disabled "all" extensions. Having lags / freezes / delays even on markup cells.
When notebook initially opened it is smoother - gets worse after a few minutes. Restarting vscode is the only thing that helps temporarily - which makes it practically impossible to work.
Hi @DonJayamanne
I have run a large notebook, both with MD and without MD. Find below the logs for both.
Best
Just adding to this. I have been having the issue shown below when hovering over Plotly graphs created with large data, which does not happen running normal Jupyter notebook on the web. Hope it helps.
@ale-dg Please can you share this notebook. Optionally feel free to email this if you do not feel comfortable sharing it here, If its still sensitve, please can you create a similar notebook with dummy data where you can experience the same slowness and get the same message about VS Code not respondig.
Just adding to this. I have been having the issue shown below when hovering over Plotly graphs created with large data, which does not happen running normal Jupyter notebook on the web. Hope it helps.
@ale-dg Please can you share this notebook. Optionally feel free to email this if you do not feel comfortable sharing it here, If its still sensitve, please can you create a similar notebook with dummy data where you can experience the same slowness and get the same message about VS Code not respondig.
I've lost the original (it was a Kaggle competition... so not very careful with it). I have found the data and reproduced the error. The last graph is the one showing the error when you hover for a while over it. Find it below.
Best
Best
@MehmetDiyar @gdebrun2 please can you share a sample notebook that can be used to replicate the issue you are running into.
@MehmetDiyar @gdebrun2 please can you share a sample notebook that can be used to replicate the issue you are running into.
Will do in the in the next couple days. Just to be clear, this issue is not exclusive to notebooks with markdown cells. I will try to provide example notebooks with no markdown and with markdown that experience this unresponsiveness.
I have the same problem working on Fedora 39 - Linux. It's driving me nuts.
I have the same issue with Code 1.87.2 on Ubuntu 23.10.
@MehmetDiyar @gdebrun2 please can you share a sample notebook that can be used to replicate the issue you are running into.
Sorry for the delay. The .ipynb in this zipped folder will reproduce the issue. I can't find a notebook with no markdown cells that's experience the rendering issue at the moment, but I will keep an eye out for it in the coming weeks.
I managed to repro the behavior in this comment by just running this cell ~50 times in the interactive window:
import plotly.express as px
import random
x = []
y = []
for i in range(100000):
random_number = random.randint(1, 10000)
x.append(i + random_number)
y.append(i + random_number)
fig = px.scatter(x, y)
fig.show()
It still doesn't happen every time, but it's enough to be able to investigate
Thanks @amunger , the code example and the referenced comment is very helpful. I can reproduce this and this might explain why we see a performance slow down for large notebook, especially when we have widgets or rich media.
My hypothesis is
When my notebooks contain many interactive plotly.express plots, the .ipynb files saved from vscode can be ~10x larger (100+MB rather than 10MB) than equivalent notebooks saved from Google Colab
This is also something we want to look into.
Some of above hypothesis validated:
Uint8Array(313597405)
, which is ~313MB.100000
x and 100000
y). \t
s before each number, and a line break after:
x
and y
axis, the more tabs/spaces and linebreaks we generate in VS CodeI'm fairly convinced that the big perf hit comes from serializing the notebook as part of the backup, in which case shrinking the file size isn't really going to help.
[backup tracker] creating backup at 2024-03-29T21:23:55.074Z *.txt
[backup tracker] storing backup at 2024-03-29T21:23:55.075Z *.txt
[backup tracker] finished backup at 2024-03-29T21:23:58.148Z *.txt
[backup tracker] creating backup at 2024-03-29T21:24:17.318Z *.ipynb
[backup tracker] storing backup at 2024-03-29T21:24:20.239Z *.ipynb
[backup tracker] finished backup at 2024-03-29T21:24:22.071Z *.ipynb
here are some perf snapshots of the backup process, top is for a text editor
One fairly simple thing to do would be to optionally treat large outputs as transient, that would avoid serializing them entirely. Plotly graphs, for example, don't seem to render successfully when loaded from disk anyway (but maybe I'm doing something wrong). But that might not be an acceptable solution to some people.
Otherwise we need to look at really optimizing the serialization, or possibly moving it off of the renderer process.
Plotly graphs, for example, don't seem to render successfully when loaded from disk anyway (but maybe I'm doing something wrong). But that might not be an acceptable solutio
If output is html mime type, then it should load from disc
Just want to say that I'm also experiencing this bug on Linux Mint 21, When the notebook starts to contain larger outputs from the cells it slows down drastically and it's basically unusable...
Every few months I try to use vscode for jupyter because I would really love to just use vscode for everything. Every few months, I am disappointed and switch back to the web version.
There are two reasons for this:
1) Jupyter for vscode continues, stubbornly, to essentially always be more slow than traditional jupyter lab on localhost. Look at the run times in this screenshot. It took me a minute to run imports; when I ran the exact same code on the localhost version, it took 7.7 seconds (pictures attached). This is an extremely consistent theme in vscode jupyter. Cells will sometimes randomly take minutes to run, and will sometimes not even run at all until you press 'shift-enter' on them twice. This has been true for me across multiple computers, in many different dev environments.
Cells also just randomly take forever to run, for god knows what reason. Here is a screenshot of assigning a string to a variable taking 27.4 seconds:
Note that I am not trying to blame the team here, I am just frustrated because this is so close to being a great product, but this one thing holds it back, and it keeps not being fixed for years on end. The very first thing I would do as a product manager if I were in charge of vscode-jupyter is to pause all current tasks and plan, with the team, a multiple-month effort to speed things up, and get cells to run effectively instantly (or as close to the amount of time the python processing of the code takes as possible), every time.
2) Jupyter for vscode sucks at inline documentation, the equivalent of
shift+tab
in vscode jupyter. I am aware of the existence of thetrigger parameter hints
andshow hover
settings in the keyboard shortcuts. These are extremely unreliable, and actually show documentation when I press the button maybe 1/5 of the time. When they do show documentation, there is a 'loading' tag for awhile. Browser jupyter, on the other hand, is immediate with this. Basically every time. Below is an example.The other issue with inline documentation is that, as far as I can tell, hover documentation for methods on instantiated variables simply doesn't work. When I am using
pandas
, for instance, typingdf.unique(
and then pressing theshow hover
hotkey while my typing carat is to the right of the parenthesis pops up a documentation window saying exactly nothing. In contrast, in the web version, typing the same thing produces full documentation, as expected.I don't understand how these two issues aren't your guys's top priority. Everyone I've spoken to who uses jupyter has had exactly the same experience as I have, and everyone I've spoken to who uses jupyter uses the web version exclusively for exactly these issues. Even Kaggle notebooks are better. I love copilot and it'd be great to bring it into my jupyter notebook experience, but it has just never been viable to switch if I don't want a workflow where I have to wait for 30 seconds every time I press
command-enter
, or I am frustratingly making a new cell above the current one and typingfunction?
just to see documentation.These issues have been ongoing since vscode jupyter started. They are the only things holding me and everyone else I've spoken to back from using it. Without fixing these issues, the whole thing is unusable, and no other features you guys put in matter. Why are you guys working on anything besides this when they are the only things anyone I know cares about?
I should note that this is all running in a docker container with access to 7 of my 8 cpus and 10gb of RAM. I am on a 2022 macbook air. I realize that this is a rant, so thank you for reading it. Nothing personal, I just think this product has a bunch of potential and I hate to see it unusable for so long.