Jupyter notebook slow to load and unresponsive
At some point one of my SageMath Jupyter notebooks became very slow to respond to the mouse and keyboard: mouse clicks now take several seconds to register and keystrokes appear only after a long lag. When the notebook is opened in a browser tab, it can take five minutes or more for any of the cells to show up. I have notebooks open in other tabs of the same browser window that load instantly and are very responsive. I'm running in Safari on a MacBook pro.
I tried many things to rectify the issue, including restarting the kernel, clearing all outputs, shutting down the kernel and restarting, shutting down the browser, shutting down the machine, and creating a copy of the notebook and running that. None of these had any effect. This notebook does not contain any graphics or any particularly large input our output cells. I finally solved the issue by extracting all input cells by hand and copying them into a fresh notebook. This fresh notebook now has essentially the same visible content as the old one, but is much more responsive and loads right away. Evidently there is some invisible content in the old notebook that is causing issues.
Can anyone suggest a work-around that is less cumbersome than what I ended up resorting to? Any ideas as to what might have caused this?
Update: In response to a suggestion from rburing, I looked at the text of my notebook files, which convinced me that there isn't any hidden information that might be causing the problem. After some experimentation, I discovered that an aspect of my old notebook that I thought completely innocuous appears to be causing the issue. That notebook contained a large number of one- or two-line calculation cells at the end that I originally didn't bother copying over to my new notebook, thinking they couldn't possibly be important. As I began copying these cells to the new notebook, that notebook also began to grind to a halt. I then did the following experiment: I created notebook1, containing 512 cells, each containing
a = 2+2
print(a)
I created notebook2 containing eight cells, each containing the above code repeated 64 times. I executed all cells in both notebooks and saved. I then restarted the web browser and loaded both notebooks. It took about 3.5 minutes for notebook1 to load, but only a few seconds for notebook2 to load.
So is the lesson from all this that one shouldn't use a notebook structure with lots of small cells?
Can you inspect the difference between the
.ipynbfile of the original notebook and the notebook with the same (visible) input cells re-evaluated? They are plain text files, and can be compared with tools likediff.Thanks for this suggestion. I have started to do this, and so far any differences are minor. I'm beginning to suspec, however, that the issue is due to a visible difference that I should have paid more attention to, and not an invisible difference. When I said that the old and new notebooks had essentially the same content, I was focused on what I thought would be the issue, namely large blocks of code and large output cells. The old file, however, has a lot of small input cells with either no output or one short line of output that I never copied over to the new file. These don't take up a large fraction of the visible real estate, and are not the major contributor to the file size, but it seems they may be what is slowing things down. I'll continue to investigate.
Do the extra cells contain LaTeX output? I've had the MathJax renderer (for LaTeX in the browser) slow my notebooks down. You could try blocking the MathJax JavaScript in your browser to test whether this is the issue.
I'm not doing any LaTeX rendering - just plain text. It's funny because notebooks of ten times the file size with lots of dense graphics and extremely large textual outputs are more responsive. I fully expected to find that my problematic notebook contained some hidden information that was causing the problem, but that seems not to be the case. I'll do some experimenting to see whether I can isolate the factor responsible for the issue.
You should answer your own question (possibly after generalizing and checking your hint), in order to be informative for the next poor sod which will stumble on this issue.
You could also suggest a patch to the documentation reporting this problem and suggesting not to multiply cells without a good reason (in my branch, this called a tumor, or a cancer ;-)...).