mkChar is a rather expensive call since it allocates a new R object. For example in reading char data from a file it is often advantageous to first try to look up an already made R string and only then use mkChar. That is, the overhead of the lookup is usually smaller than that of mkChar.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jan T. Kim > Sent: Wednesday, April 13, 2005 3:44 AM > To: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] How allocate STRSXP outside of gc > > On Tue, Apr 12, 2005 at 12:31:03PM -0700, Vadim Ogranovich wrote: > > Hi, > > > > I am trying to figure a way to allocate a string SEXP so that gc() > > won't ever collect it. > > > > Here is a little bit of a background. Suppose I want to write a > > .Call-callable function that upon each call returns the same value, > > say > > mkChar("foo"): > > > > SEXP getFoo() { > > return mkChar("foo"); > > } > > > > The above implementation doesn't take advantage of the fact that > > mkChar("foo") could be pre-computed only once, and then the > function > > would return the pre-computed value. So the question is how > to create > > this precomputed value. > > > > > > The closest thing I could find in the sources is > R_NaString, but I was > > not able to trace down how it comes about. > > For being unaffected by R's memory management, it may be the > best to not use a SEXP for storing the pre-computed result at > all. Rather, use a static variable "private" to your code, as in > > SEXP getFoo() > { > static char *foo = NULL; > > if (foo == NULL) > { > foo = the_difficult_to_compute_value_of_foo(); > } > return mkChar(foo); > } > > This way, getFoo indeed invokes mkChar each time, but in your > scenario, that might be an overhead which is negligible > compared to the actual computation of the foo value. > > Best regards, Jan > -- > +- Jan T. Kim > -------------------------------------------------------+ > | *NEW* email: [EMAIL PROTECTED] > | > | *NEW* WWW: http://www.cmp.uea.ac.uk/people/jtk > | > *-----=< hierarchical systems are for files, not for humans > >=-----* > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel