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
Mesa currently runs model execution and visualization rendering on the same thread, creating performance bottlenecks when running computationally intensive models with multiple visualizations. This impacts responsiveness, especially in Jupyter notebooks. The UI can lag or freeze during model execution since visualization updates block the main thread.
We could improve performance by leveraging Solara's use_thread() functionality to run visualizations on separate threads from model execution. This would allow the model to continue executing while visualizations update asynchronously.
There could be (at least) three threads:
Main thread for model execution
Separate thread for Solara UI/event handling
Worker thread pool for rendering visualizations (plots, space drawings, etc.)
Some key questions to resolve:
How to handle thread synchronization between model and vis? (and how much is need? One direction or bi?)
Should threading be configurable or always enabled?
Thread per component vs shared thread pool?
Next steps would be to prototype basic thread separation, benchmark improvements, and document the threading behavior.
Mesa currently runs model execution and visualization rendering on the same thread, creating performance bottlenecks when running computationally intensive models with multiple visualizations. This impacts responsiveness, especially in Jupyter notebooks. The UI can lag or freeze during model execution since visualization updates block the main thread.
We could improve performance by leveraging Solara's
use_thread()
functionality to run visualizations on separate threads from model execution. This would allow the model to continue executing while visualizations update asynchronously.There could be (at least) three threads:
Some key questions to resolve:
Next steps would be to prototype basic thread separation, benchmark improvements, and document the threading behavior.
See also:
CC @quaquel @Corvince
The text was updated successfully, but these errors were encountered: