performance of .Primitive and .Internal

The reason .Internal(paste0(.Primitive("list")("this","and","that"),NULL)) is slower seems to be because of what Josh O'Brien guessed. Calling .Primitive("list") directly incurs some additional overhead.

You can see the effects via a simple example:

require(compiler)
pl <- cmpfun({.Primitive("list")})
microbenchmark(list(), .Primitive("list")(), pl())
# Unit: nanoseconds
#                  expr  min     lq median     uq   max neval
#                list()   63   98.0  112.0  140.5   529   100
#  .Primitive("list")() 4243 4391.5 4486.5 4606.0 16077   100
#                  pl()   79  135.5  148.0  175.5 39108   100

That said, you're not going to be able to improve the speed of .Primitive and .Internal from the R prompt. They are both entry points to C code.

And there's no reason to try and replace a call to .Primitive with .Internal. That's recursive, since .Internal is itself a primitive.

> .Internal
function (call)  .Primitive(".Internal")

You'll get the same slowness if you try to call .Internal "directly"... and a similar "speedup" if you compile the "direct" call.

Internal. <- function() .Internal(paste0(list("this","and","that"),NULL))
Primitive. <- function() .Primitive(".Internal")(paste0("this","and","that"),NULL)
cPrimitive. <- cmpfun({Primitive.})
microbenchmark(Internal., Primitive., cPrimitive., times=1e4)
# Unit: nanoseconds
#         expr min lq median uq  max neval
#    Internal.  26 27     27 28 1057 10000
#   Primitive.  28 32     32 33 2526 10000
#  cPrimitive.  26 27     27 27 1706 10000