Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Code profiling for Shiny app?

For an R Shiny web app, what are some good ways to run code profiling that show the parts of the Shiny code that are taking the most processing time?

I've got a big, fat, complex Shiny app, and I'd like to figure out where in this labyrinth of code I'm slowing my Shiny app down the most. I've tried out Rprof and profr but haven't gotten much insight from them.

like image 826
canary_in_the_data_mine Avatar asked Jan 31 '14 15:01

canary_in_the_data_mine


People also ask

Can you save Shiny app as HTML?

You need an R server in order to execute a shiny app. There is no way to convert it into "pure HTML" and run the interactivity via javascript. The reason for that is that shiny apps will have to execute R code at runtime and javascript does not know how to deal with that.

How do you structure a Shiny app?

Shiny applications have two components, a user interface object and a server function, that are passed as arguments to the shinyApp function that creates a Shiny app object from this UI/server pair. The source code for both of these components is listed below.

How do I use Shiny Profvis?

To do this, simply execute the runApp() command inside of profvis . For instance, we can run one of shiny's built-in examples using the runExample command (which is a wrapper for runApp ). Your Shiny application will launch, and after interacting and closing the app a profile will be generated.


Video Answer


3 Answers

I think this question needs a little update, therefore I am adding another answer to it...

You can use the package profvis to profile shiny apps as well. It will give flame graphs directly for your R code. I.e. no need to use Chrome's flame graphs and guess where the bottleneck is. You will know exactly where to change your code.

Here is how to do it:

  1. Run shiny app via Profvis
  2. Interact with your shiny app
  3. Close browser
  4. Stop Console via Stop button
  5. Load profile
  6. If Step 5 fails, try this: Convert to html if needed (memory problems)

Details for certain steps are added below:

Step 1: Run profvis

library(profvis)
profvis({ runApp('directory_of_shiny_app') }  
    , prof_output = '/directory_to_save_profile')

Step 5: Load your profile

profvis(prof_input = '/path_to_save_output/random_name.Rprof') 

N.B. Profvis gives a random name to your file. So you need to change the input path accordingly

Step 6: Convert to html

This step might be needed, if you have a huge app and flame graph gets a little bit longer. You might get an error "Pandoc:... memory"

p <- profvis(prof_input = '/path_to_save_output/file108f93bff877b.Rprof')
htmlwidgets::saveWidget(p, "/path_to_save_output/profile.html")

Then open the html file in your browser.

like image 99
Buggy Avatar answered Oct 18 '22 22:10

Buggy


A few (rough) ideas:

  1. Profiling the app in the browser might help. I have a largish app that uses navbarPage and the page build speed was getting slow. Using profiling in Chrome (developer tools) identified the 'culprit'. A fix/improvement is in the works https://github.com/rstudio/shiny/issues/381#issuecomment-33750794
  2. Run the profiler from a code window in your app. Using the shinyAce package (https://github.com/trestletech/shinyAce) I can edit (and run) code, including profilers from within the app (i.e., call reactives etc.). See link below (R > Code). Note that code evaluation is deactivated on the server but the source code for the app is on github if you want to try this out (see About page)
  3. Write your code in regular R functions that are called by reactive functions. I am in the process of rewriting my app so that it can use knitr for 'reproducible research' (R > Report). This restructuring makes it easier to use profiling libraries from R(studio) without starting the app.
  4. Rselenium is an R interface to Selenium, testing tools for web-apps (https://github.com/johndharrison/RSelenium). I have only just started using this but you perhaps you could use this with something like system.time to compare speeds for different components.

http://vnijs.rady.ucsd.edu:3838/marketing/

like image 45
Vincent Avatar answered Oct 18 '22 20:10

Vincent


From my experiences:

  1. Plugin print() in the functions You can find out which function takes most of the time. For example:

mydebug <- function(msg="[DEBUG]") { DEBUG <- FALSE if (DEBUG) { print(sprintf("%s - %s - %s", msg1, as.character(Sys.time()), as.character(deparse(sys.calls()[[sys.nframe()-1]])))) } } f <- function() { mydebug() ## your original function definitions ..... mydebug() return(...) ## the returned value needs to be after mydebug() }

  1. Use Chrome flame graph to profile

You can obtain a flame to find out where the time spent (e.g., which JS function? Is it due to layout?).

enter image description here

For details, refer to: https://developers.google.com/web/tools/chrome-devtools/profile/rendering-tools/analyze-runtime?hl=en

like image 2
zhanxw Avatar answered Oct 18 '22 22:10

zhanxw