Cripplingly slow UI: am I the only one?

Hello everyone,
I am facing the same issue and hoping both, my additional information enable solution finding and I can work normally again.

I use a MacBook Pro 16GB M1 Processor and run Jupiter Lab on Chrome, locally.

Up until yesterday everything was working fine. I connected to Postgre db with psycopg2 (initial setup was a struggle).
Then I made the mistake to install the git extension, which totally broke the running system. Nothing worked anymore, also not after running “Jupyter Lab build”.
So i spent the day uninstalling, reinstalling packages and installing everything new via homebrew. Here I am not sure whether I did so before as well.

Finally, I got the PostgreS connector working again but even trying to open the menus (File, View, Run, Kernel etc) are responding super slow in very small test notebooks, like 5 commands to establish the connection.

As I am not a developer (but Analyst) I definitely do not understand the system and setup. Hence, if you have advice, I would very much appreciate it.
If I can support by trying anything (like uninstall-reinstall any certain way), I am totally open for it (my setup is really not that complex to rebuild I believe)

Thank you all for your efforts in making this tool and community so great.

Are there any errors or warnings in the browser javascript console? (on Chrome, View > Developer > Javascript Console menu item). What version of JupyterLab, and what plugins are installed? Does it also slow down with just JupyterLab installed without any plugins?

Hi Jason, thanks for getting back so fast and looking into this.
I think it is rather warnings, the Chrome Console shows me:

When I check for jupyter version I receive the following information:

ipykernel        : 6.4.2
ipywidgets       : 7.6.5
jupyter_client   : 7.0.6
jupyter_core     : 4.8.1
jupyter_server   : 1.11.1
jupyterlab       : 3.2.1
nbclient         : 0.5.4
nbconvert        : 6.2.0
nbformat         : 5.1.3
notebook         : 6.4.5
qtconsole        : 5.1.1
traitlets        : 5.0.5

What version of JupyterLab

I would assume this is then 3.2.1, right?

what plugins are installed?

The git extension was the first I dared trying to install and uninstall right after it crashed the system. Other than that, none that I am aware of. Any command to check this?

Does it also slow down with just JupyterLab installed without any plugins?

Would love to check this. Could you tell me how to safely validate whether plugins are installed or not?

Also, when I did set it up again, Jupyter did not load any kernels. I installed ipykernels (more than once). It does show the Python3 Kernel now. Maybe there is still an issue in that direction though?

I changed default browser to Firefox and it was performing better. Both are functional. Neither Chrome nor FF are as performant as before I messed up the system though.

The Chrome Network Monitor shows issues, I assume in some requests. Maybe they are indicating anything:
||name||status||type||size||time||
|terminals?1634907502287|(canceled)|fetch|244ms|
|kernels?1634907502301|(canceled)|fetch|229ms|
|sessions?1634907502305|(canceled)|fetch|226ms|
|kernelspecs?1634907502380|(canceled)|fetch|151ms|
|channels?session_id=d23587e3-c06c-434a-8b76-d352390b383b|101|websocket|Pending|
|channels?session_id=0a1a2c0b-2a74-4377-b2e9-be96c30717cc|101|websocket|Pending|

Hope the additional information is helping in this regard. I am very grateful for your support. Thanks a lot!

If all fails, would you be able to tell me how to do a clean sweep and do a complete new install of any python installs (except the once the OS needs of course). As I really only use or intent to use it in combination with Jupyter. No more extensions for me though :wink:

From command line/terminal:

jupyter labextension list

and

jupyter serverextension list

and

jupyter server extension list

Then I made the mistake to install the git extension, which totally broke the running system. Nothing worked anymore, also not after running “Jupyter Lab build”.

I would not give up on extensions just yet. The build step is indeed problematic and can sometimes break things (if aborted at a wrong moment) - that’s why most extensions transitioned away from it. The currently recommended pip install jupyterlab-git (or conda equivalent) should not result in any build request.

Having said that, yes jupyterlab-git has in past been seen causing a deadlock in specific circumstances when there is a git lockfile present (and possibly there is another undiscovered bug in some atypical circumstances). In that case I would suspect that you could have uninstalled the frontend extension, but the server extension could still be installed and possibly contributing to the slowness by being stuck due to a lockfile. This would not be the case if you installed the extensions using the pip/conda way only (really hard to know without knowing which exact instructions you followed - I know that there are some severely outdated ones in tutorials around the web which pin to outdated versions).

Thank you for the detailed guidance, and shared experience.

jupyter labextension list

provides: JupyterLab v3.2.1

jupyter serverextension list

does not return any additional information

jupyter server extension list

Config dir: /Users/<my_user_name>/.jupyter

Config dir: /opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/etc/jupyter

Config dir: /usr/local/etc/jupyter

the server extension could still be installed and possibly contributing to the slowness by being stuck due to a lockfile. (…) really hard to know without knowing which exact instructions you followed

Unfortunately I can not really tell for certain anymore. Am very annoyed about that myself. If all fails, is there any chance for a clean sweep still?

Hello, do you happen to have any further ideas how to address this? In between it was more usable as long as one only stayed within one tab of jupyter lab.
Now, it does hardly react at all anymore. In case it helps, I add a screenshot from the terminal, which now throws a lot of Exceptions.

When launching jupyter lab it shows the following:

[I 2021-11-02 13:32:42.122 ServerApp]  jupyterlab | extension was successfully linked.
[I 2021-11-02 13:32:42.163 LabApp] JupyterLab extension loaded from /opt/homebrew/lib/python3.9/site-packages/jupyterlab
[I 2021-11-02 13:32:42.163 LabApp] JupyterLab application directory is /opt/homebrew/Cellar/python@3.9/3.9.7_1/Frameworks/Python.framework/Versions/3.9/share/jupyter/lab
[I 2021-11-02 13:32:42.165 ServerApp] jupyterlab | extension was successfully loaded.
[I 2021-11-02 13:32:42.165 ServerApp] Serving notebooks from local directory: /Users/<user>
[I 2021-11-02 13:32:42.165 ServerApp] Jupyter Server 1.11.1 is running at:
[I 2021-11-02 13:32:42.165 ServerApp] http://localhost:8888/lab?token=45f88603676f34e5622f81191f2e3404683367dbbe83821b
[I 2021-11-02 13:32:42.165 ServerApp]  or http://127.0.0.1:8888/lab?token=45f88603676f34e5622f81191f2e3404683367dbbe83821b

after waiting to be able to navigate in the notebook let alone execute any action, I recognize these error/exceptions being raised in the terminal:

[W 2021-11-02 14:07:50.009 ServerApp] Notebook Documents/notebooks/nfs/dwh_staging_view.ipynb is not trusted
[W 2021-11-02 14:08:43.310 ServerApp] Timeout waiting for kernel_info reply from 5092e7dc-1529-4570-8bb0-07cad0d046e4
[W 2021-11-02 14:08:43.313 ServerApp] 404 GET /api/kernels/5092e7dc-1529-4570-8bb0-07cad0d046e4/channels?session_id=9028fb72-3a66-45e2-bbde-6dd0b0589029 (::1): Kernel does not exist: 5092e7dc-1529-4570-8bb0-07cad0d046e4
Exception in callback <bound method WebSocketMixin.send_ping of ZMQChannelsHandler(5092e7dc-1529-4570-8bb0-07cad0d046e4)>
    Traceback (most recent call last):
      File "/opt/homebrew/lib/python3.9/site-packages/tornado/ioloop.py", line 905, in _run
        return self.callback()
      File "/opt/homebrew/lib/python3.9/site-packages/jupyter_server/base/zmqhandlers.py", line 189, in send_ping
        self.ping(b"")
      File "/opt/homebrew/lib/python3.9/site-packages/tornado/websocket.py", line 445, in ping
        raise WebSocketClosedError()
    tornado.websocket.WebSocketClosedError 

If the complete screenshot makes sense, I can definitely add this as well.

Any idea what I could do to have this operational again is much appreciated.

Thanks a lot,
Christian

Windows 10 build 1909 , memory 16G (15.7G available) so is not lack of memory.
Chrome 95.0.4638.69 , 64 bits
Jupyter lab v3.1.18
Chrome DevTools (F12 debugger) logs a repeating activity like this:

  • I have another computer with almost same config above but it works fine and the F12 debugger logs is totally quiet. Therefore the above picture is pointing to the problem root cause.
  • I also tried different .ipynb files, same problem.
  • Jupyter notebook works a little better but also shooting the similar logs and that make the laggings.
  • Only Jupyter notebook folder without opening any notebook is totally ok.

@hcchen where are the async_sequence.js and browser_chrome.js coming from? It does not look like any part of the core JupyterLab. Maybe you have an extension (JupyterLab extension, or a browser extension) that causes the slowdown?

1 Like

very very important info to me, I can proceed to check them out then…
thank you sooooo much.

Good news, I have fixed it.

My case is caused by a software named “Avaya IX workplace” that’s the
dcePageScanner::ParsePage matching ((?<head>[\.\s]*|^|[^\$\£\w])((?<country>\({0,1}\+[0-9]{1,3}\){0,1}){0,1}(?<seperator>\s{0,1}[/\.\-]{0,1}\s{0,1})(?<code>\([0-9]{0,6}\)){0,1}(?<body>\s{0,1}[/\.\-0-9\s\(\)]*[0-9]{1,15}))(?<tail>[^@\$\£\w]|$))|(((\b|\B)(pc|passcode|pswd|pw|pass|pin|access|passwort|kennwort|kw|zugangscode|Zugriff|ca|códigoacceso|contraseña|ctsñ|acceso|accesso|パスコード|パスワード|パス|アクセス|암호|패스코드|비밀번호|비번|패스|액세스|senha|sen|sh|codigo|acesso|密码|口令|访问)|\(P\))([^\w0-9#\*]*)(?<passcode>[0-9#,\*\s]+))
shown as above on my Chrome DevTools F12 debugger. Can be easily fixed by uninstalling it.

2 Likes

I also encountered this problem. However it only seems to occur while I have a contextual help window open. If I close the contextual help then the interface speeds up again.Which is fine except the contextual help window is one of the JupyterLab features that I tend to use a lot during development.

2 Likes

Can confirm Donald’s observation. Closing the contextual help window speeds up the UI. The lags are gone when working without contextual help window.

When contextual help window is open, the white dot (kernel activity indicator) is often turning black for seconds while typing code. While kernel activity indicator is black (active), the UI does not respond to keyboard. The typed text gets drawn delayed to the UI, just after the kernel goes back to idle.

This is a fresh install of python 3.10 & jupyterlab. Started a new virtualenv (just jupyterlab, numpy, matplotlib), and no further jupyterlab extensions have been installed. Running on firefox 91.3.0esr (64 bit). Windows10.

Steps to reproduce:

  1. Install Python10 from python.org.
  2. Install git.
  3. Create new directory, open git bash within this directory.
  4. pip install pipenv

  5. pipenv shell

  6. pipenv install jupyterlab matplotlib numpy

  7. jupyter-lab

  8. Start typing python code, observe lags and kernel activity during typing.
  9. Close contextual help window.
  10. Type python code and observe lags. Compare with lags at step 8.

Expected result: Lags at step 8 and 10 should be comparable.
Result I get: Lags at step 8 are much longer (seconds) compared to step 10 (instant rendering of typed text).

The contextual help window is one of the greatest features of jupyterlab. I really would like to have it back working without lag, as it was for several months before the lags started.

I can also confirm, that very slow JupyterLab UI is occuring (for me) only when “Contextual Help” is open and visible (tab has to be active).
There can be lags several seconds for many actions in this case, otherwise lags aren’t noticable.

I have the same issue: UI gets ~unusable with large number of cells in the notebook (active tab, inactive tabs seem to not affect it), even with 1 notebook.

Freshly updated jupyterlab v3.2.5, no lab/server extensions.

Although, I have python 3.8.

I get some warnings when running the lab:

/home/username/.local/lib/python3.8/site-packages/nbclassic/notebookapp.py:73: FutureWarning: The alias `_()` will be deprecated. Use `_i18n()` instead.
  _("Don't open the notebook in a browser after startup.")
...
[241009:241009:0100/000000.638398:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.

No warnings in JS console.

Some strange observations:

  • scrolling with the scroller is fast;
  • scrolling with the mouse wheel lags for a few seconds and then seems ok; especially lags when at the top of the notebook…
  • “switching” between active tab and the left sidebar makes huge lag; e.g. doing stuff in the notebook goes smooth, switching to the kernel list takes a few seconds; now, switching between file-browser/kernel-list is fast, but starting to do things in the notebook is preceeded with a huge lag.

I am using SageMath ipykernel, but this should not matter I guess.

Not using contextual help at all.

Laptop with i5-10210U CPU @ 1.60GHz, 64 GiB RAM. OS Linux Mint, browser Brave (tried firefox and chrome).

I’m experiencing slowness on fresh notebooks (<10 code cells, no more than 3 lines of code each) running on a docker container.
Although the virtualization it self my contribute to this performance issue, I’m also experiencing it on my OS build.
The thread seems rather quiet but i thought an isolated environment like a docker container might help reproduce this issue for someone willing to investigate further. I’ll need to trim out some of my company’s stuff but, after that, I’m willing to share it.

Just wanted to +1 here, since this at least subjectively appears to have gotten worse recently. Hopefully not adding noise to the discussion, but I’m seeing the same symptoms as the original post. Even with simple notebooks getting lots of lag scrolling around, editing code cells, etc. If I switch to classic notebook via help → launch classic notebook everything is nice and snappy again.

If it helps I’m running the notebook remotely on GCE and hosting config files on an NFS mount. Not sure if that would contribute to this

Hi,
I’m just here to share my experience on JupyterLab.

Recently I was experiencing very slow interface response (especially in the terminal opened via jupyterLab) and in the jupyterLab interface.

After doing so many tests (reinstalling different versions of anaconda, different virtual environments, different versions of python and other applications) for days, I finally found the different cases that lead to slowdown and of course the case where JupyterLab works well !
In the attached image at the end of the post, I’ve written “KO” for the slowdown situation and “OK” if there is no slowdown.

To reproduce the problem, just create a new environment via anaconda (or manually) and launch jupyterLab, then create an empty notebook, run the first empty cell, then open a terminal tab (in case KO you should already see that opening the terminal is lonnnnnng) then try typing a few words into termin, it will feel awfully slow!

See attached photo for cases, thanks.

Hi,
I’m bringing today another FIX detail.
When creating new virtual env with python >= 3.7 till python < 3.10 and installing jupiter lab >= 3.0.11 we enter then the KO case which can be fixed by installing Spyder (5.1.5)
In that case, installing spyder is no longer needed ! :
Indeed, if your current (in you virtual env) package “jupyter_client” version == 7.1.0 then just downgrade it to 7.06 via the Anaconda navigator Environments Tab !

Conclusion : something goes wrong with 7.1.0 version of “jupyter_client” package when using jupyterlab !

Enjoy ! :wink:

1 Like

THANK YOU SO MUCH !!!

A simple pip install jupyter_client==7.0.6 solved it for me

I have been using JupyterLab since it first became available. Occasionally I experienced slowness problems in the past. Lately, since version 3.x was introduced, I have not really experienced any significant slowness problems. I experienced problems with GCP, Azure, and other cloud platforms, so I just run it locally.