Suggestions on how extension can mitigate JupyterLite lazy kernal cold-start?

JupyterLab extensions
,
1

I’m using JupyterLite in an environment where first-time user experience is really important. I noticed that when I load up a JupyterLite notebook, the first time a code cell executes there is a ~15 second delay. After that, code cells execute very fast.

My application includes a JupyterLab / JupyterLite extension. I was wondering, does anyone have a suggestion for reducing this delay on first-cell execution?

My user will probably be reading for the first 10 seconds or so that they’re looking at the notebook. If I could force a code cell to execute as soon as the notebook opens, that would solve my problem for a lot of users. This seems clumsy though.

Can someone with recommend a pattern for reducing this cold start time?

2

@OwenBrown maybe a workaround could be to have an extension that finds the first cell and executes it automatically when the notebook is first opened?

Which Python kernel are you using? Pyodide or Xeus Python?

Pyodide loads packages lazily depending on the code being executed, which can explain this delay when executing a cell.

Xeus Python on the other hand fetches all packages at kernel startup, which should make executing the first cell faster:

xeus-python-package-load

However the drawback is kernel startup time which can be longer due to more files being downloaded.

2 Likes
3

Over in GitHub - krassowski/jupyterlab-transformers-completer: Inline completion provider using tranformers.js for JupyterLab I am “working around” the issue of language models taking time to download by showing a notification with a progress bar which dynamically updates as the model gets downloaded. This is just a UX mitigation but it does wonders to reducing user annoynace.

I was recently thinking whether JupyterLite would benefit from showing a progress bar to indicate that packages are being downloaded. What do you all think?

2 Likes
4

A lite kernel can implement this, already, but would require a custom client extension and a custom kernel extension and a custom server extension, as there is no formalized place in the messaging spec at this stage of the lifecycle.

As there are a number of expensive-to-start 0MQ-based kernels (and wrappers) as well, perhaps the kernel messaging protocol would benefit from some ways to reflect this kind of early lifecycle kernel status information, and then lite kernels could use it.

The UX of how to actually deliver this is another story: the status indication primitives in Lab and Notebook are… not super informative. The “pie chart” for queued cells tells one something, and was a good change over the previous ternary, but there really isn’t room in that menu and status bar (which often duplicate information from the menu bar) for every feature to add another gizmo. Notifications toasts are pretty terrible, from an attention-management point of view, if they don’t offer something actionable.

All the cool kids have ~8px tall “skinny flowing ribbons”, maybe we need concrete/indeterminate/stackable one of those under the toolbar that can optionally reveal the log message viewer.

2 Likes
5

Thank you for the quick response. I’m using Pyodide. I’ll read up on the tradeoffs of Pyodide vs. Xeus Python.

6

How to add xpython to the jupyterLite environment?
pip install xpython did’nt work for me?

I figured it out.