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

Select too many columns and it just breaks #257

Open
mccalluc opened this issue Feb 27, 2025 · 3 comments
Open

Select too many columns and it just breaks #257

mccalluc opened this issue Feb 27, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@mccalluc
Copy link
Contributor

Construct a CSV with 20 columns and just keep adding them. Shiny can't keep up and the UI becomes unresponsive.

I think (but haven't tested this hypothesis) that plot generation is expensive.

  • Display only one preview plot at a time?
  • Hard limit on the number of columns that can be selected?
  • Less recalculation? Make things lazier / less reactive?
  • More caching of results?
@mccalluc
Copy link
Contributor Author

Started a PR

but I wonder if part of the solution is non-blocking operations with Shiny. Need to do more research.

@mccalluc
Copy link
Contributor Author

There are at least two problems using non blocking operations. 😦

They are intended as a wrapper for calculations: What was reactive is now called as a regular function. Since the slow part for us is the plot, I'm not sure how to change this to a function invocation:

ui.output_plot("histogram_preview_plot", height="300px"),

But even if that worked, while non blocking operations don't block other code, they still block themselves:

An extended task can run concurrently to reactive code and to other extended tasks–that’s its whole purpose. However, a single extended task object cannot run itself multiple times concurrently. If you call sum_values() while it is already running, it will enqueue the new invocation and run it after the first one completes.

They acknowledge that this is often not desired: The fix is a widget that blocks the user from enqueing more operations. I don't know that a UI that blocked user operations would be any better than one where they get backlogged.

👉 New idea: There are many plotting libraries out there: speed might not usually be the deciding factor, but worth looking at in this case.

@mccalluc
Copy link
Contributor Author

No obvious switch that just makes it faster. possible next steps

  • Time the rendering code: if we'll be making experiments to speed this up, we need numbers. Playing with the UI and seeing how it feels is not enough.
  • Switch out matplotlib backends. Does it make a difference?
  • Profile the whole thing: I've assumed plot_histogram is the bottleneck, but not super confident
  • Is it incrementally updating the plot? That could be expensive. Make sure we're only rendering once.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Pending
Development

No branches or pull requests

1 participant