Unless the function itself has a very short execution time, overhead incurred by the call should be negligible. Same for a pipe.
2
3
Indeed. difficult to imagine code that does anything at all where this would matter much in practice, but yes there is technically "some overhead" to the parentheses
2
1
I think I’d was Radfird Neal, or maybe @hadleywickham , years ago pointing out that braces are faster than parentheses. Maybe it was @burnsstat ? It’s been so long I don’t think I can track it down.
2
1
Sure, I vaguely remember that going around, but there's also a reason @MattDowle is on record as hating microbenchmarks. If you speed up something by 5x but it was taking 0.000001% of total runtime (a number I made up but prolly not unrealistic for braces/parens)...
1
2
Hey. It’s been a decade :). That was R 2.11. I think that was part of the impetus for pqR.
That being said microbenchmarking has its place, but it’s so much more important to profile.
1
1
I've never met Radford Neal but I'm aware of his work and have heard of him and from what I hear the brackets/parens thing is something that would def bother him a lot. I don't recall if thats one of his patches that made it into #rstats since or not (many have and more haven't)
1
1
2
I did. and read it. The code he used is a) much faste rnow, about 10x and I can take partial credit for that (tho most goes to Luke) cause that 1:n isn't getting evaluated. but disregarding that f and g take pretty much identical amounts of time now on average
1
3
Oh. No question that #rstats has much improved since those days.
1
1
1
You may have been thinking of the 'curlies versus parens versus ...' example computing 1/x different ways which I used a few times in Rcpp tutorials.
It goes back, if memory serves, to Christian Robert.
I can dig up a reference if someone truly cares.
Jul 22, 2020 · 3:18 PM UTC
4
2
