similar to: enableJIT in Rprofile leads to 'not a proper evaluation environment' on startup

Hello, Due to exploration of the JIT capabilities offered through the {compiler} package, I came by the fact that using enableJIT(2) can *slow* the rpart function (from the {rpart} package) by a magnitude of about 10 times. Here is an example code to run: library(rpart) require(compiler) enableJIT(0) # just making sure that JIT is off # We could also use enableJIT(1) and it would be fine fo

Hi, Browser doesn't work properly with the compiler enabled. It might be intended behavior, but it's not documented. compiler::enableJIT(1) foo <- function(){ browser() cat("here\n") } Browser doesn't stop, and I am getting: > foo() Called from: foo() Browse[1]> here > Thanks, Vitalie. > sessionInfo() R version 2.14.2 (2012-02-29) Platform:

I'm not sure if this is a bug or expected behavior, but I don't see anything in the documentation that explains it, so I thought I'd mention it: ~ michaelweylandt$ R -q --vanilla library(compiler) enableJIT(3) `+` # Throws an error `+` # Throws a warning `+` # Prints the primitive as expected sessionInfo() R version 2.14.1 (2011-12-22) Platform: i386-apple-darwin9.8.0/i386

In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r Andrew Leach has raised a question about the memory usage of my package nleqslv. In a model with a loop within a function he has experienced continuously increasing memory usage by package nleqslv

Hello, JIT compiler interferes with internal R completions: compiler::enableJIT(2) utils:::functionArgs("density", '') gives: utils:::functionArgs("density", '') Note: no visible global function definition for 'bw.nrd0' Note: no visible global function definition for 'bw.nrd' Note: no visible global function definition for 'bw.ucv'

Thanks. This should be resolved in R-devel(r72788) and R-patched (r72789) Best, luke On Mon, 12 Jun 2017, Berend Hasselman wrote: > > > In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html > and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r > > Andrew Leach has raised a question

Hi, I'm running into a case where byte-compilation changes the semantic of a function. This is with R 3.4.0: foo <- function(x) { TRUE && x } foo(c(a=FALSE)) # [1] FALSE # OK foo(c(a=TRUE)) # [1] TRUE # OK foo(c(a=FALSE)) # a # ???? # FALSE The 3rd call returned a result that it different from the 1st call! After

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ##

Hi! We?ve seen a problem with the compiler in specific cases of matrix updates: > { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; } ; m } [,1] [,2] [1,] 1 3 [2,] 2 99 Here, it modifies element [2,2], which is unexpected. It behaves correct without the loop: > { m <- matrix(1:4, 2) ; z <- 0; m[z <- z + 1,z <- z + 1]

Hi, this post is about foreach operators, the compiler package and the last update of doMC that includes support for the compiler functionality. I am using a home-made %dopar%-like operator that adds some custom expression to be executed before the foreach loop expression itself (see sample code below). It used to work perfectly with doMC 1.2.1, but with the introduction of the compiler

> .Internal(inspect(1:10)) @300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) > .Internal(inspect(seq(1,10))) @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... > system.time(1:1e7) user system elapsed 0 0 0 > system.time(seq(1,1e7)) user system elapsed 0.05 0.00 0.04 It seems that result of function 'seq' doesn't use compact

Hi, I am running into a problem when I use the window<- replacement function in R 3.4.0. It will lead to an error when it is called inside a loop, probably the result of the byte compiler now enabled by default. When I turn it off, it works again, as in older versions of R. I tested on Win, Linux and Mac, and the problem occurs everywhere. Here is a reproducible example: z <-

A shorter reproducible example: example(makeActiveBinding) for (fred in 1:3) { 0 } ls() Both problems go away if you first do compiler::enableJIT(2) So looks like a bug in compiling the for loop. -Deepayan On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel <r-devel at r-project.org> wrote: > > Possibly just a symptom of the earlier behavior, but I'll amend my

Dear All, In R 3.4.2 (Linux), the compiler seems to have regressed: $ R --vanilla g = function() { N = 1e7; ans = numeric(N) system.time({for (j in 1:N) ans[j] = 1}) } g() # user system elapsed # 4.272 0.000 4.272 g1 = compiler::cmpfun(g) g1() # user system elapsed # 4.232 0.004 4.235 Running the above code in Windows 3.3.1, g() takes the same time, but g1() takes around 0.5

Thanks -- I'll commit a fix after some testing. Best, luke On 04/29/2018 06:22 AM, Duncan Murdoch wrote: > On 28/04/2018 11:11 PM, Suharto Anggono Suharto Anggono via R-devel wrote: >>> .Internal(inspect(1:10)) >> @300e4e8 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact) >>> .Internal(inspect(seq(1,10))) >> @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...

Thanks for the report. Fixed in R_devel with r72631; I'll port to R-patched later today or tomorrow. The default setting and how to get the current settings are documented in the Details section of the enableJIT help page at the end of the paragraph for enableJIT. Best, luke On Wed, 26 Apr 2017, Herv? Pag?s wrote: > Hi, > > I'm running into a case where byte-compilation

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found

It looks like the byte compiler is optimizing local() to an immediately-invoked function, instead of using eval() and substitute(). I don't know if that's exactly how it's implemented internally, but that's what it looks like here: compiler::enableJIT(0) fun <- function(x) { local(sys.calls()) } fun(1) ## [[1]] ## fun(1) ## ## [[2]] ## local(sys.calls()) ## ## [[3]] ##

Dear R-devel list, Running the following example on a recent R-devel (here, 2016-11-22 r71672) shows that the byte compiler can cause some significant performance drops (here, computation time increasing from 0.01s to 0.31s ...) ================================= library(Matrix) someMatrix <- new("dtCMatrix", i= c(1L, 0:3), p=c(0L,0L,0:2, 5L), Dim = c(5L, 5L), x

On 26/04/2017 4:36 PM, Herv? Pag?s wrote: > Hi, > > I'm running into a case where byte-compilation changes > the semantic of a function. This is with R 3.4.0: > > foo <- function(x) { TRUE && x } > > foo(c(a=FALSE)) > # [1] FALSE # OK > > foo(c(a=TRUE)) > # [1] TRUE # OK > > foo(c(a=FALSE)) > #