MCP HubMCP Hub
Volver a habilidades

optimize-shiny-performance

pjt222
Actualizado 2 days ago
8 vistas
17
2
17
Ver en GitHub
Metageneral

Acerca de

Esta habilidad ayuda a los desarrolladores a perfilar y optimizar aplicaciones Shiny lentas o no responsivas utilizando técnicas como almacenamiento en caché, operaciones asíncronas y control de flujo reactivo. Proporciona herramientas para identificar cuellos de botella y es ideal para preparar aplicaciones para producción con alta carga concurrente. Las capacidades clave incluyen profvis, bindCache, memoise y el manejo de cálculos de larga duración con ExtendedTask.

Instalación rápida

Claude Code

Recomendado
Principal
npx skills add pjt222/agent-almanac -a claude-code
Comando PluginAlternativo
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternativo
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/optimize-shiny-performance

Copia y pega este comando en Claude Code para instalar esta habilidad

Documentación

Optimize Shiny Performance

Profile + opt: caching, async, reactive graph.

Use When

  • Slow / unresponsive interaction
  • Server resources exhausted under concurrent load
  • Specific ops bottleneck (data load, plot, compute)
  • Prep for prod w/ many users

In

  • Required: Path to Shiny app
  • Required: Perf problem desc (slow load, laggy, high mem)
  • Optional: Expected concurrent users
  • Optional: Server resources (RAM, CPU cores)
  • Optional: DB or API used?

Do

Step 1: Profile

# Profile with profvis
profvis::profvis({
  shiny::runApp("path/to/app", display.mode = "normal")
})

# Or profile specific operations
profvis::profvis({
  result <- expensive_computation(data)
})

ID top bottlenecks:

  1. Data load: initial fetch time?
  2. Reactive recalc: which reactives fire most?
  3. Render: which outputs slowest?
  4. External: DB queries, API, file I/O?

Reactive log for graph analysis:

# Enable reactive logging
options(shiny.reactlog = TRUE)
shiny::runApp("path/to/app")
# Press Ctrl+F3 in the browser to view the reactive graph

→ Clear ID of 2-3 biggest bottlenecks.

If err: profvis not detailed → wrap specific sections w/ profvis::profvis(). Reactlog overwhelming → focus one interaction at a time.

Step 2: Opt reactive graph

Cut unnecessary invalidations.

# BAD: Recomputes on ANY input change
output$plot <- renderPlot({
  data <- load_data()  # Runs every time
  filtered <- data[data$category == input$category, ]
  plot(filtered)
})

# GOOD: Isolate data loading from filtering
raw_data <- reactive({
  load_data()
}) |> bindCache()  # Cache the expensive part

filtered_data <- reactive({
  raw_data()[raw_data()$category == input$category, ]
})

output$plot <- renderPlot({
  plot(filtered_data())
})

isolate() to prevent unnecessary invalidations:

# Only recompute when the button is clicked, not on every input change
output$result <- renderText({
  input$compute  # Take dependency on button
  isolate({
    paste("N =", input$n, "Mean =", mean(rnorm(input$n)))
  })
})

debounce() + throttle() for high-freq inputs:

# Debounce text input — wait 500ms after user stops typing
search_text <- reactive(input$search) |> debounce(500)

# Throttle slider — update at most every 250ms
slider_value <- reactive(input$slider) |> throttle(250)

→ Reactive graph fires only necessary recalcs.

If err: removing dep breaks → use req() for explicit guards instead of implicit reactive deps.

Step 3: Caching

bindCache for outputs

output$plot <- renderPlot({
  create_expensive_plot(filtered_data())
}) |> bindCache(input$category, input$date_range)

output$table <- renderDT({
  expensive_query(input$filters)
}) |> bindCache(input$filters)

bindCache uses inputs as cache keys. Same inputs → cached result returned immediately.

memoise for fns

# Cache expensive function results
load_reference_data <- memoise::memoise(
  function(dataset_name) {
    readr::read_csv(paste0("data/", dataset_name, ".csv"))
  },
  cache = cachem::cache_disk("cache/", max_age = 3600)
)

App-level pre-compute

# In global.R or outside server function — computed once at app startup
reference_data <- readr::read_csv("data/reference.csv")
model <- readRDS("models/trained_model.rds")

server <- function(input, output, session) {
  # reference_data and model are available to all sessions
  # without reloading
}

→ Repeated ops use cache; response time drops.

If err: cache too big → set max_age / max_size. Stale → reduce max_age or cache-clear button. bindCache errors → ensure cache key inputs serializable.

Step 4: Async for long ops

ExtendedTask (Shiny ≥ 1.8.1):

server <- function(input, output, session) {
  # Define the extended task
  analysis_task <- ExtendedTask$new(function(data, params) {
    promises::future_promise({
      # This runs in a background process
      run_heavy_analysis(data, params)
    })
  }) |> bind_task_button("run_analysis")

  # Trigger the task
  observeEvent(input$run_analysis, {
    analysis_task$invoke(dataset(), input$params)
  })

  # Use the result
  output$result <- renderTable({
    analysis_task$result()
  })
}

For Shiny < 1.8.1, promises directly:

library(promises)
library(future)
plan(multisession, workers = 4)

server <- function(input, output, session) {
  result <- eventReactive(input$compute, {
    future_promise({
      Sys.sleep(5)  # Simulate long computation
      expensive_analysis(isolate(input$params))
    })
  })

  output$table <- renderTable({
    result()
  })
}

→ Long ops don't block UI; other users can interact during.

If err: future_promise errors → check plan(multisession) set. Vars unavailable in future → pass explicitly (separate R process).

Step 5: Opt rendering

Cut render overhead.

# Use plotly for interactive plots instead of re-rendering
output$plot <- plotly::renderPlotly({
  plotly::plot_ly(filtered_data(), x = ~x, y = ~y, type = "scatter")
})

# Use server-side DT for large tables
output$table <- DT::renderDataTable({
  DT::datatable(large_data(), server = TRUE, options = list(
    pageLength = 25,
    processing = TRUE
  ))
})

# Conditional UI to avoid rendering hidden elements
output$details <- renderUI({
  req(input$show_details)
  expensive_details_ui()
})

→ Render faster, no UI block.

If err: plotly slow w/ big data → toWebGL() or downsample before plot.

Step 6: Validate

# Before/after benchmarking
system.time({
  shiny::testServer(myModuleServer, args = list(...), {
    session$setInputs(category = "A")
    session$flushReact()
  })
})

# Load testing with shinyloadtest
shinyloadtest::record_session("http://localhost:3838")
shinyloadtest::shinycannon(
  "recording.log",
  "http://localhost:3838",
  workers = 10,
  loaded_duration_minutes = 5
)
shinyloadtest::shinyloadtest_report("recording.log")

→ Measurable improvement in response times / concurrent capacity.

If err: no improvement → re-profile for next bottleneck. Iterative — fix biggest first, re-measure.

Check

  • Profiling IDs specific bottlenecks (not guessing)
  • Reactive graph: no unnecessary invalidation chains
  • Expensive ops use cache (bindCache/memoise)
  • Long ops use async (ExtendedTask/promises)
  • High-freq inputs use debounce/throttle
  • Big data → server-side
  • Improvement measurable (before/after)

Traps

  • Premature opt: profile first. Bottleneck rarely where you think
  • Cache invalidation bugs: stale data → cache key missing inputs. Add deps to bindCache()
  • Future variable scoping: future_promise = separate process. Globals, DB conns, reactive vals → capture explicitly
  • Reactive spaghetti: too complex graph → architectural refactor (modules), not just cache
  • Over-caching: caching all = waste mem. Only expensive ops w/ repeated input patterns

  • build-shiny-module — modular arch for maintainable reactive code
  • scaffold-shiny-app — pick right framework from start
  • deploy-shiny-app — deploy optimized w/ proper resources
  • test-shiny-app — perf regression tests

Repositorio GitHub

pjt222/agent-almanac
Ruta: i18n/caveman-ultra/skills/optimize-shiny-performance
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Habilidades relacionadas

content-collections

Meta

Esta habilidad proporciona una configuración probada en producción para Content Collections, una herramienta centrada en TypeScript que transforma archivos Markdown/MDX en colecciones de datos con tipado seguro mediante validación Zod. Úsala al construir blogs, sitios de documentación o aplicaciones Vite + React con mucho contenido para garantizar seguridad de tipos y validación automática de contenido. Abarca todo, desde la configuración del plugin de Vite y compilación MDX hasta la optimización de despliegue y validación de esquemas.

Ver habilidad

polymarket

Meta

Esta habilidad permite a los desarrolladores crear aplicaciones con la plataforma de mercados de predicción Polymarket, incluyendo la integración de API para operaciones y datos de mercado. También proporciona transmisión de datos en tiempo real a través de WebSocket para monitorear operaciones en vivo y actividad del mercado. Úsela para implementar estrategias de trading o crear herramientas que procesen actualizaciones de mercado en tiempo real.

Ver habilidad

creating-opencode-plugins

Meta

Esta habilidad ayuda a los desarrolladores a crear complementos de OpenCode que se conectan a más de 25 tipos de eventos, como comandos, archivos y operaciones LSP. Proporciona la estructura del complemento, las especificaciones de la API de eventos y los patrones de implementación para módulos en JavaScript/TypeScript. Úsala cuando necesites interceptar, monitorear o extender el ciclo de vida del asistente de IA de OpenCode con lógica personalizada basada en eventos.

Ver habilidad

sglang

Meta

SGLang es un framework de alto rendimiento para el servicio de LLM que se especializa en generación rápida y estructurada para JSON, expresiones regulares y flujos de trabajo de agentes utilizando su caché de prefijos RadixAttention. Ofrece una inferencia significativamente más rápida, especialmente para tareas con prefijos repetidos, lo que lo hace ideal para salidas complejas y estructuradas, y conversaciones multiturno. Elige SGLang sobre alternativas como vLLM cuando necesites decodificación restringida o estés construyendo aplicaciones con uso extensivo de prefijos compartidos.

Ver habilidad