Within C++ functions, how are Rcpp objects passed to other functions (by reference or by copy)?

Question

I've just finished writing a new version of the ABCoptim package using Rcpp. With around 30x speed ups, I'm very happy with the new version's performance (vs old version), but I'm still having some concerns on if I have space to improve performance without modifying too much the code.

Within the main function of ABCoptim (written in C++) I'm passing around a Rcpp::List object containing "bees positions" (NumericMatrix) and some NumericVectors with important information for the algorithm itself. My question is, when I'm passing a Rcpp::List object around other functions, e.g.

#include <Rcpp.h>

using namespace Rcpp;

List ABCinit([some input]){[some code here]};
void ABCfun2(List x){[some code here]};
void ABCfun3(List x){[some code here]};

List ABCmain([some input])
{
  List x = ABCinit([some input]);
  while ([some statement])
  {
    ABCfun2(x);
    ABCfun3(x);
  }
  ...

  return List::create(x["results"]);
}

What does Rcpp does within the while loop? Does the x object is passed by reference or by deep copy to the functions ABCfun2 and ABCfun3? I've seen the usage of 'const List&x', which tells me that I can pass Rcpp objects using pointers, but the thing is that I need this list to be variable (and no constant), is there anyway to improve this? I'm afraid that iterative copy of this x List can be slowing down my code.

PS: I'm still new to C++, furthermore I'm using Rcpp to learn C++.

Answer 1

There is no deep copy in Rcpp unless you ask for it with clone. When you pass by value, you are making a new List object but it uses the same underlying R object.

So the different is small between pass by value and pass by reference.

However, when you pass by value, you have to pay the price for protecting the underlying object one more time. It might incur extra cost as for this Rcpp relies on the recursive not very efficient R_PreserveObject.

My guideline would be to pass by reference whenever possible so that you don't pay extra protecting price. If you know that ABCfun2 won't change the object, I'd advise passing by reference to const : ABCfun2( const List& ). If you are going to make changes to the List, then I'd recommend using ABCfun2( List& ).

Consider this code:

#include <Rcpp.h>
using namespace Rcpp  ;

#define DBG(MSG,X) Rprintf("%20s SEXP=<%p>. List=%p\n", MSG, (SEXP)X, &X ) ;

void fun_copy( List x, const char* idx ){
    x[idx] = "foo" ;
    DBG( "in fun_copy: ", x) ;

}
void fun_ref( List& x, const char* idx ){
    x[idx] = "bar" ;
    DBG( "in fun_ref: ", x) ;
}


// [[Rcpp::export]]
void test_copy(){

    // create a list of 3 components
    List data = List::create( _["a"] = 1, _["b"] = 2 ) ;
    DBG( "initial: ", data) ;

    fun_copy( data, "a") ;
    DBG( "\nafter fun_copy (1): ", data) ;

    // alter the 1st component of ths list, passed by value
    fun_copy( data, "d") ;
    DBG( "\nafter fun_copy (2): ", data) ;


}

// [[Rcpp::export]]
void test_ref(){

    // create a list of 3 components
    List data = List::create( _["a"] = 1, _["b"] = 2 ) ;
    DBG( "initial: ", data) ;

    fun_ref( data, "a") ;
    DBG( "\nafter fun_ref (1): ", data) ;

    // alter the 1st component of ths list, passed by value
    fun_ref( data, "d") ;
    DBG( "\nafter fun_ref (2): ", data) ;


}

All I'm doing is pass a list to a function, update it and print some information about the pointer to the underlying R object and the pointer to the List object ( this ) .

Here are the results of what happens when I call test_copy and test_ref:

> test_copy()
           initial:  SEXP=<0x7ff97c26c278>. List=0x7fff5b909fd0
       in fun_copy:  SEXP=<0x7ff97c26c278>. List=0x7fff5b909f30

after fun_copy (1):  SEXP=<0x7ff97c26c278>. List=0x7fff5b909fd0
$a
[1] "foo"

$b
[1] 2

       in fun_copy:  SEXP=<0x7ff97b2b3ed8>. List=0x7fff5b909f20

after fun_copy (2):  SEXP=<0x7ff97c26c278>. List=0x7fff5b909fd0
$a
[1] "foo"

$b
[1] 2

We start with an existing list associated with an R object.

           initial:  SEXP=<0x7fda4926d278>. List=0x7fff5bb5efd0

We pass it by value to fun_copy so we get a new List but using the same underlying R object:

       in fun_copy:  SEXP=<0x7fda4926d278>. List=0x7fff5bb5ef30

We exit of fun_copy. same underlying R object again, and back to our original List :

after fun_copy (1):  SEXP=<0x7fda4926d278>. List=0x7fff5bb5efd0

Now we call again fun_copy but this time updating a component that was not on the list: x["d"]="foo".

       in fun_copy:  SEXP=<0x7fda48989120>. List=0x7fff5bb5ef20

List had no choice but to create itself a new underlying R object, but this object is only underlying to the local List. Therefore when we get out of get_copy, we are back to our original List with its original underlying SEXP.

after fun_copy (2):  SEXP=<0x7fda4926d278>. List=0x7fff5bb5efd0

The key thing here is that the first time "a" was already on the list, so we updated the data directly. Because the local object to fun_copy and the outer object from test_copy share the same underlying R object, modifications inside fun_copy was propagated.

The second time, fun_copy grows its local List object, associating it with a brand new SEXP which does not propagate to the outer function.

Now consider what happens when you pass by reference :

> test_ref()
           initial:  SEXP=<0x7ff97c0e0f80>. List=0x7fff5b909fd0
        in fun_ref:  SEXP=<0x7ff97c0e0f80>. List=0x7fff5b909fd0

  after fun_ref(1):  SEXP=<0x7ff97c0e0f80>. List=0x7fff5b909fd0
$a
[1] "bar"

$b
[1] 2

        in fun_ref:  SEXP=<0x7ff97b5254c8>. List=0x7fff5b909fd0

  after fun_ref(2):  SEXP=<0x7ff97b5254c8>. List=0x7fff5b909fd0
$a
[1] "bar"

$b
[1] 2

$d
[1] "bar"

There is only one List object 0x7fff5b909fd0. When we have to get a new SEXP in the second call, it correctly gets propagated to the outer level.

To me, the behavior you get when passing by references is much easier to reason with.

Answer 2

Briefly:

1. void ABCfun(List x) passes by value but then again List is an Rcpp object wrapping a SEXP which is a pointer -- so the cost here is less than what a C++ programmer would suspect and it is in fact lightweight. (But as Romain rightly points out, there is cost in an extra protection layer.)

2. void ABCfun(const List x) promises not to change x, but again because it is a pointer...

3. void ABCfun(const List & x) looks most normal to a C++ programmer and is supported in Rcpp since last year.

Ipso facto, in the Rcpp context all three are about the same. But you should think along the lines of best C++ practice and prefer 3. as one day you may use a std::list<....> instead in which case the const reference clearly is preferable (Scott Meyers has an entire post about this in Effective C++ (or maybe in the companion More Effective C++).

But the most important lesson is that you should not just believe what people tell you on the internet, but rather measure and profile whenever possible.

Answer 3

I'm new to Rcpp so figured i'd answer @Dirk's request for a measurement of the cost of the two passing styles (copy and reference) ...

There is surprisingly little difference -- between the two approaches.

I get the below:

microbenchmark(test_copy(), test_ref(), times = 1e6)
Unit: microseconds
        expr   min    lq     mean median    uq        max neval cld
  test_copy() 5.102 5.566 7.518406  6.030 6.494 106615.653 1e+06   a
   test_ref() 4.639 5.566 7.262655  6.029 6.494   5794.319 1e+06   a

I used a cut-down version of @Roman's code: removing the DBG calls.

#include <Rcpp.h>
using namespace Rcpp;

void fun_copy( List x, const char* idx){
    x[idx] = "foo";
}

void fun_ref( List& x, const char* idx){
    x[idx] = "bar";
}

// [[Rcpp::export]]
List test_copy(){

    // create a list of 3 components
    List data = List::create( _["a"] = 1, _["b"] = 2);

    // alter the 1st component of the list, passed by value
    fun_copy( data, "a");

    // add a 3rd component to the list
    fun_copy( data, "d");
    return(data);

}

// [[Rcpp::export]]
List test_ref(){

    // create a list of 3 components
    List data = List::create( _["a"] = 1, _["b"] = 2);

    // alter the 1st component of the list, passed by reference
    fun_ref( data, "a");

    // add a 3rd component to the list
    fun_ref( data, "d");
    return(data);

}

/*** R

# benchmark copy v. ref functions
require(microbenchmark)
microbenchmark(test_copy(), test_ref(), times = 1e6)

*/