You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The introspection and change detection done by the Environment pane can have unwanted side effects. These are all examples of problems that we have historically had:
increasing memory consumption by accidentally forcing early evaluation
bumping reference counts unintentionally and preventing garbage collection
creating unnecessary copies of data during formatting and display
dramatically decreasing performance as a side effect of change detection or pathologically slow formatting
triggering inescapable debug loops (code evaluated during the course of building the pane triggers the debugger, which rebuilds the pane, which ...)
Because it is not possible to close RStudio's Environment pane (it is effectively a singleton on both the client and the server), we built a feature into it that allows one to disable the auto-refresh feature. Users experiencing any of the above ill effects can thus turn it off to prevent (or at least rule out) the Environment pane as a source of trouble.
This is not currently possible in Positron. Positron's architecture does not use singletons, but does have a code-enforced 1:1 correspondence between Environment front ends and language runtimes: currently we create an Environment client for every language runtime, and host it in a headless service, attaching it to the UI in another layer.
This makes it impossible to disable the Environment features on the back end; we create the front end even if the UI is not visible, and it stays around even when the UI is closed.
We should provide a safety bypass somewhere to make it possible to work in a language runtime without the Environment pane active. Some possible approaches:
bind the lifetime of the front end client instance to the UI widget (it's okay to repeatedly create and destroy these since they automatically send new lists when created); rely on the user to show/hide the pane as a way to enable/disable
imitate RStudio's feature and have a latch that turns off the back-end's introspection without otherwise altering the shape of the pane
petetronic
changed the title
Provide a way to close or disable the Environment pane client
Variables View: Provide a way to close or disable the Variables client
Nov 23, 2023
For example, this notebook runs in ~14 seconds when change detection is enabled in the Python kernel. When it's disabled, it runs in ~4 seconds (the same time taken in Jupyter Notebook with a standard ipykernel). That's 3.5x slower!
That said, the notebook uses from x import * which probably introduces more variables than a typical user would have.
The introspection and change detection done by the Environment pane can have unwanted side effects. These are all examples of problems that we have historically had:
Because it is not possible to close RStudio's Environment pane (it is effectively a singleton on both the client and the server), we built a feature into it that allows one to disable the auto-refresh feature. Users experiencing any of the above ill effects can thus turn it off to prevent (or at least rule out) the Environment pane as a source of trouble.
This is not currently possible in Positron. Positron's architecture does not use singletons, but does have a code-enforced 1:1 correspondence between Environment front ends and language runtimes: currently we create an Environment client for every language runtime, and host it in a headless service, attaching it to the UI in another layer.
https://github.com/rstudio/positron/blob/1d10e4283129cfcc2f492d56222611f784cd0036/src/vs/workbench/services/positronEnvironment/common/positronEnvironmentService.ts#L96-L116
This makes it impossible to disable the Environment features on the back end; we create the front end even if the UI is not visible, and it stays around even when the UI is closed.
We should provide a safety bypass somewhere to make it possible to work in a language runtime without the Environment pane active. Some possible approaches:
The text was updated successfully, but these errors were encountered: