benchmarking tmap

[hbermeo]

Why is it that drawing maps with tmap is too much but too slow? with other methods like ggplot or plot they are fast in comparison.

[mtennekes]

Thanks for this constructive feedback @hbermeo !

I'll leave this issue open: reproducible examples that are suitable for benchmarking can be posted and discussed here.

[hbermeo]

Okay, this would be an example where we take some data and when drawing it in ggplot it takes some time and in tmap it takes about 5 or 6 times more time. Would it be possible to improve the time it plots?

library(sf)
library(tmap)
library(sp)
library(ggplot2)

# load data ------------------------------------------------------------

denuncia_v = read.csv("https://github.com/hbermeo/datos_espaciales/raw/master/denuncia_vial.csv",
                encoding = "UTF-8")

## coordinates
coordinates(denuncia_v) = ~long + lat
denuncias = st_as_sf(denuncia_v)
st_crs(denuncias) = 4326

## Plot
ggplot(data= denuncias) + geom_sf(alpha = 0.1)
tm_shape(denuncias) + tm_dots(alpha = 0.1)

[mtennekes]

Thanks, very useful example. Now it's a lot faster, to my own surprise even faster than ggplot2. Please check and let me know if you encounter any other issues.

Background: the computation time is caused my sf::st_is_valid and to a lesser extend sf::st_is_empty. A year or two ago, I decided to make those checks in the preprocessing phase, since otherwise further in the process errors may occur, at the cost of being slower. For tmap is made sense to do so, since it does a few more things than plot and mapview, where valid shape data is required.

Now, I adapted a different approach. I've added a tmap option called "check.and.fix", which is by default FALSE. So for sf objects, the sf::st_is_valid and sf::st_is_empty checks are bypassed by default. This makes tmap a lot faster. In order to still produce useful errors/warnings, a few tryCatches are placed at functions that may go wrong for invalid sf objects.

[hbermeo]

Perfect is now much better

[Nowosad]

@mtennekes Awesome. I made some timings, and on my computer the difference between the previous and the current version is about 25 seconds vs 2 seconds.

[Robinlovelace]

Amazing work Martijn and all, this will make tmap even more user friendly!

[mtennekes]

Thx! I've done a little benchmarking: see https://github.com/mtennekes/tmap/blob/master/sandbox/benchmark.Rmd Feel free to improve/extend this script.

tmap is now eqally fast and sometimes even faster thanggplot2. It might be a tad slower than 2 weeks ago, since I've re-enabled st_is_empty. However, the slowness was caused by st_is_valid.

[Robinlovelace]

Heads-up @mtennekes I've checked-out the continuous benchmarking functionality and it seems to work pretty well - if you add something like this you could have continuous benchmarks tracking changes automatically: https://github.com/luukvdmeer/sfnetworks/pull/64

[assignUser]

Hey @mtennekes if you are still interested in CB I would like to mention {touchstone} which will run benchmarks and comment them on the PR after every push! We are getting ready to submit to rOpenSci and CRAN. Now is a good time to test it, we would love some feedback from new users!

[kadyb]

I wanted to revisit this issue. While the performance of plotting raster objects in {stars}, {terra} and {tmap} is similar, {tmap} is several times slower than the others for vector data. Edit: I opened new issue here: https://github.com/r-tmap/tmap/issues/704.

[Nowosad]

@kadyb thanks! Can you open a new issue about that? (Also, please run the code using the tmap version 4 -- remotes::install_github("r-tmap/tmap@v4"))