> so skipping the entire object is not really an option. Understood - just wanted to highlight the existence of Rcpp::is_nan / Rcpp::any in case they were broadly relevant.
> Nevertheless, the question still remains why the rcpp isNaN call is so > much slower. Take care to distinguish the R-core ISNAN macro, the R_IsNaN function, and the Rcpp::isNaN template function. Asides from sugar-stuff, all the examples discussed here so far address the performance of R-core ISNAN, given doubles that are accessed via Rcpp, correct? I'm not qualified to answer, but your example piqued my interest. Based on your previous email, I'm guessing you found this? "Currently in C code ISNAN is a macro calling isnan. (Since this gives problems on some C++ systems, if the R headers is called from C++ code a function call is used.) " http://www.hep.by/gnu/r-patched/r-exts/R-exts_133.html Definitions from the horse's mouth: https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Arith.h#L66 Based on the above, I added permutations to a *very* minimal test (no return val, etc) that include Romain's suggestion: https://github.com/helmingstay/rcpp-timings/tree/master/minimal ## source('benchmarks.r') I see that: A) the sugar expression in slow B) based on timings, ISNAN appears to call R_isnancpp, which is slow C) std::count_if yields a modest improvement given B) D) Using an inline function matching the definintion of ISNAN used in a C envir [i.e., "isnan(xx)!=0", using math.h] appears to incur no cost at all (example CountNans_expr) This doesn't get to the *why*, but perhaps addresses the question of intrinsic limitations in Rcpp. Perhaps others can comment on whether D) is equivalent to driving without a seatbelt. hth, -Christian -- A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama! http://www.x14n.org/ _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
