Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel performance decrease even if variableInspector's UI not opened #307

Closed
jhgoebbert opened this issue Jul 25, 2024 · 4 comments
Closed

Comments

@jhgoebbert
Copy link

jupyterlab-variableInspector is a fantastic extension ...
.. but it comes with the drawback that it runs (of course) some extra code in the kernel which can lead to a significant slow down.
https://github.com/jupyterlab-contrib/jupyterlab-variableInspector/blob/main/src/kernelconnector.ts#L94

At the moment, jupyterlab-variableInspector runs by default for every Python and R kernel, regardless of whether the user has opened its UI or not. For this reason, jupyterlab-variableInspector cannot be a default extension for a JupyterLab installation that is used by many different users. It must always be an optional extension as it has high impact on the execution performance.

It would be great if jupyterlab-variableInspector could execute extra commands in the kernel only if the users has opened its UI.

@martinRenou
Copy link
Member

Thanks for opening an issue and raising this!

It would be great if jupyterlab-variableInspector could execute extra commands in the kernel only if the users has opened its UI.

This sounds fair, I will look into what it takes to do this.

Although I believe it may not be enough, because if the UI for the variable inspector is opened the issue would appear. The slowdown seems to appear after a huge dataframe has been created in the kernel.
I will also look into the pain points in the case where such a dataframe is created and see if we can improve things.

@martinRenou
Copy link
Member

@jhgoebbert would you be able to provide a sample notebook that shows this slowdown in your particular case? That would help me see if I can improve other things

@martinRenou
Copy link
Member

I guess we can close this now. The situation should be improved now with #309, #311, #313, #319 and #320

@jhgoebbert
Copy link
Author

Hi @martinRenou ,
I am sorry that my answer comes late - I was too busy in the last week until now.
Great, that the situation improved with the fixes you listed 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants