Profile ggplot2 and grid performance

[dpseidel]

No description provided.

[dpseidel]

mirror of grid
external repository of profiling results

@tmastny and I are interested in pulling together a list of potential avenues of attack for improving grid and ggplot2 performance, additional links/issues/ideas/discussion are appreciated.

Currently open issues identify these two areas for improvement:

• improved text handling:
  • geom_label versus geom_text (as @clauswilke points out in this comment)
  • specifically the descentDetails function as pointed out by @thomasp85 and discussed in more detail among separate grid issues in Descent heights still not right #2687
• performance with geom_sf not all of which should be addressed in ggplot2/grid but is under discussion in Ploting POINT sf with geom_sf() is slow #2718 and previously in geom_sf is appallingly slow in some cases #2655.

[clauswilke]

There are two parts to grid in the way we use it: (i) construction of grobs; (ii) rendering of grobs. I have looked primarily at part (i), but I have some ideas for part (ii) also.

For part (i), I see extensive room for speed improvement. Most importantly, units, grobs, and gpars are all rather simple data structures, and grid uses a large amount of code to generate them. If one wrote lightweight code to generate them, maybe even in C++, one could get a significant speed boost. I provided an example here.

It might also be useful to write special-purpose unit functions, e.g. the equivalent of:

unit_pt <- function(x) unit(x, "pt")

but implemented directly in C++.

For part (ii), I noticed how complex the drawing code is that gets called when we do grid.draw(x). There are no special-purpose functions for commonly used grobs such as points or text. As a consequence, for example, we call makeContent.default() and makeContext.default() on every points grob, even though these functions do nothing. It looks to me like there's significant room for improvement there as well.

[tmastny]

ggplot's geom_path also seems significantly slower than base and lattice line plots. Here's an example from this profile:

[paleolimbot]

I know @thomasp85 has implemented a bit of this...the previous work is really cool! I put that test suite into the (very experimental) ggdebug package as ggbench() (which wraps around the bench package):

# remotes::install_github("paleolimbot/ggdebug")
library(ggdebug)
ggbench()
#> Warning: Some expressions had a GC in every iteration; so filtering is
#> disabled.
#> # A tibble: 4 x 7
#>   stage  expression      min   median `itr/sec` mem_alloc `gc/sec`
#>   <fct>  <bch:expr> <bch:tm> <bch:tm>     <dbl> <bch:byt>    <dbl>
#> 1 spec   basic       970.1µs      1ms    963.      1.95MB     21.6
#> 2 build  basic        8.61ms   9.09ms    108.      3.54MB     26.2
#> 3 draw   basic       27.82ms  31.96ms     31.9     2.97MB     87.8
#> 4 render basic      109.94ms 117.77ms      8.68   978.7KB     13.9

plot(ggbench(ggbench_standards(which = NULL)))
#> Warning: Some expressions had a GC in every iteration; so filtering is
#> disabled.

#> Warning: Some expressions had a GC in every iteration; so filtering is
#> disabled.

#> Warning: Some expressions had a GC in every iteration; so filtering is
#> disabled.
#> Loading required namespace: tidyr

^{Created on 2019-06-25 by the reprex package (v0.2.1)}

[thomasp85]

I think we can safely close this issue

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/