Porting loops and Spatial object construction to Rcpp about stplanr HOT 13 CLOSED

Great. I'll try to get a PR with Rcpp-ed lines2routes as soon as I can ...

from stplanr.

Wow - this will greatly improve performance. @mpadge will benchmark your new work and hope to see at least a halving of run-time on typical beefy applications ;)

As a general point, where's a good place to put benchmarks?

I note that in sfr the demo folder is used - sound like a plan?

E.g.: https://github.com/edzer/sfr/blob/6f2d6a64d6caf4eb159d9f808c0b16a47759fab5/demo/bm_wkb.R

from stplanr.

Nup, look about 2/3 of the way through this bit of the R extensions manual. The demo folder serves to demo the utility of the package. (And i think edzer is interpreting that a bit too flexibly with sf.) The highly structured nature of R extensions doesn't really allow for benchmarks, which I'd suggest leaves recourse only to git-specific places which in turn (short of junking up the .Rbuildignore) leaves just the wiki, as I've done for osmdata benchmarks.

from stplanr.

Hmm OK - really if R wants to be an efficient language I think package authors should be given a recommended 'home' for their benchmarks, which I guess should only build on local builds (e.g. when building the public facing README or vignettes).

In absence of any inspiration from above I politely tag experienced R package authors @hadley and @csgillespie for guidance on this question: where to put benchmarks in packages?

I've also asked this as a question to the world here as I imagine the answer will be of use/interest to others: http://stackoverflow.com/questions/40976077/where-should-package-authors-place-benchmarks

from stplanr.

To be honest, I think where you store the code is of secondary importance to where you store the results, since you really want to be running the benchmarks on every push, and storing the results in such a way that you can identify performance regressions. This is crying out for an external service like for code coverage.

I think tests/benchmarks would be a reasonable place for the code to live.

from stplanr.

Thanks for the fast reply.

Agree re automated storage of the results with each push to identify regressions.

The next stage is to find out how to do this - my understanding is that it can be done with something like codecov.io and reported on a page like this one: https://codecov.io/github/hadley/dplyr?branch=master

But I'm not sure precisely how...

Really useful and agree tests/benchmarks sounds like an entirely reasonable long-term home for these important benchmarking tests.

from stplanr.

Also - here's my source of information of code coverage in R - having speed read it I'm still not 100% sure how it works but imagine others will figure it out in double time: https://github.com/jimhester/covr/blob/master/vignettes/how_it_works.Rmd

from stplanr.

Code coverage only stores what lines of code were covered, not how long it took.

from stplanr.

Ah OK. Suggest storing the results in tests/benchmarks and calling those from the README.Rmd to print them for all to see as the default option, unless someone has a better suggestion.

from stplanr.

... sorry, i should have looked a bit deeper before opening my mouth / typing hands on that one. The loops mentioned in #151 can't be usefully benchmarked because they're API calls. These are thus quite non-ideal candidates for Rcpp-ification. In the absence of any better or preferred suggestions, I could maybe start on od_radiation?

from stplanr.

od_radiation does seem like a good candidate to start off with. I still think that some of the loops mentioned in #151 could be reasonably ported to Rcpp by restructuring them so that constructing the SpatialLines is done after all the calls have been made, rather than immediately after each call. Probably still best to start off with more straightforward functions.

from stplanr.

What's you view on this @richardellison ? Happy to close if it's gone stale.

from stplanr.

Nudge @richardellison - suggest we close for now.

from stplanr.