search for: tracemem

Hi Expert I want to use dtrace to monitor the content change of one file. I made following scripts, #!/usr/sbin/dtrace -s inline int MYPID = $1; syscall::write:entry /pid == MYPID/ { tracemem(arg1, arg2); printf("\n"); } It always has an following error bash-3.00$ sudo dumpFIFO.dtrace 3836 dtrace: failed to compile script ./dumpFIFO.dtrace: line 19: tracemem( ) argument #2 must be a non-zero positive integral constant expression When I change it to tracemem(arg1, 1);...

...============================== >>> Code and output 1: > gc( ) used (Mb) gc trigger (Mb) max used (Mb) Ncells 131180 7.1 350000 18.7 350000 18.7 Vcells 136261 1.1 786432 6.0 573372 4.4 > nn <- 1000000 > ll <- list(xx = rnorm(nn), yy = rnorm(nn)) > tracemem(ll) [1] "<0x1e32c38>" > tracemem(ll$xx) [1] "<0x2af22e144010>" > tracemem(ll$yy) [1] "<0x2af22e8e6010>" > ll$xx <- seq_len(nn) > untracemem(ll) > untracemem(ll$xx) > untracemem(ll$yy) > > tracemem(ll) [1] "<0x1e32c38...

Hi all, I've been trying to get a better handle on what manipulations lead R to duplicate a vector, creating small experiments and using tracemem to observe what happens (all in 2.15.1). That's lead me to a few questions, illustrated using the snippet below. x <- 1:10 tracemem(x) # [1] "<0x1058f8238>" x[5] <- 5 # tracemem[0x1058f8238 -> 0x105994ab0]: x[11] <- 11 Why does x[5] <- 5 create a copy, when x[11...

...tion is attached and the C function can be compiled with R CMD SHLIB test.c.) First include the c function: dyn.load("test.so") Let's start with 2 arrays: a <- rep(0, 5) b <- rep(1, 5) Now print the memory addresses: print(sprintf("a: %s b: %s", tracemem(a), tracemem(b) )) [1] "a: <0x29d34e0> b: <0x29946e0>" oky, they are different! Now copy a into b and print again the addresses: b <- a print(sprintf("a: %s b: %s", tracemem(a), tracemem(b) )) [1] "a: <0x29d34e0> b: <0x29d34...

Hi, I've noticed that as.vector() always allocates a new object, e.g. > x <- 1:10; > x <- as.vector(x); > tracemem(x); [1] "<0x0000000005622db8" > x <- as.vector(x); tracemem[0x0000000005622db8 -> 0x0000000005622ec0]: as.vector > x <- as.vector(x); tracemem[0x0000000005622ec0 -> 0x0000000005622f18]: as.vector > x <- as.vector(x); tracemem[0x0000000005622f18 -> 0x000000000...

...ference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that element doesn't result in a copy. (We know this because nothing is printed when we do the assignment after the tracemem call.) This is as expected. x <- list(1) tracemem(x) # [1] "<0x1149e08f8>" x[[1]] <- 2 # (No output) Similarly, modifying a list contained in a list doesn't result in a copy: e <- list(x = list(1)) tracemem(e$x) # [1] "<0x11b3a4b38>" e...

I was trying to use tracemem to look at mblk contents. First, I tried to use mblk->b_wptr - mblk->b_rptr as the size, and was told that it had to be a constant. Foo. (RFE #1). Then, I tried to use 8 as the size, and kept getting decimal numbers printed. Stumbled on #pragma D option rawbytes=true (is the =true neces...

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255 <===== first link_id 0 1 2 3 4 5 6 7 8 9 a b c d...

Hi, $ R --vanilla R version 2.14.1 (2011-12-22) Platform: i686-pc-linux-gnu (32-bit) > DF = data.frame(a=1:3,b=4:6) > DF a b 1 1 4 2 2 5 3 3 6 > tracemem(DF) [1] "<0x8898098>" > names(DF)[2]="B" tracemem[0x8898098 -> 0x8763e18]: tracemem[0x8763e18 -> 0x8766be8]: tracemem[0x8766be8 -> 0x8766b68]: > DF a B 1 1 4 2 2 5 3 3 6 > Are those 3 copies really taking place? Matthew

...does *not always* help in such setups. It is likely to also affect the evaluation of code chunks of various vignette engines. BACKGROUND: If you run the following at the prompt, you get that the assignment of the first element does *not* cause an extra copy of 'x': > x <- 1:2 > tracemem(x) [1] "<0x000000001c5a7b28>" > x[1] <- 0L > x [1] 0 2 However, it you source() the same code (with print.eval=FALSE; the default), you get: > code <- " x <- 1:2 tracemem(x) x[1] <- 0L " > source(textConnection(code)) tracemem[0x0000000010504e20...

I've been playing with passing arguments to .C(), and found that replacing as.double(x) with if(is.double(x)) x else as.double(x) saves time and avoids one copy, in the case that x is already double. I suggest modifying as.double to avoid the extra copy and just return x, when x is already double. Similarly for as.integer, etc. [[alternative HTML version deleted]]

Hello all, A friend recently brought to my attention that vector assignment actually recreates the entire vector on which the assignment is performed. So for example, the code: x[10]<- NA # The original call (short version) Is really doing this: x<- replace(x, list=10, values=NA) # The original call (long version) # assigning a whole new vector to x Which is actually doing this: x<-

Is putting a variable into a list a deep copy (and is tracemem the correct way to confirm)? warmstrong at krypton:~/dvl/R.packages$ R > x <- rnorm(1000) > tracemem(x) [1] "<0x3214c90>" > x.list <- list(x.in.list=x) tracemem[0x3214c90 -> 0x2af0a20]: > Is it possible to put a variable into a list without causing a deep copy...

...that someone could shed some light > on why this is happening. > > I'll start with a simple example. Below, x is a list with one element, > and changing that element doesn't result in a copy. (We know this > because nothing is printed when we do the assignment after the > tracemem call.) This is as expected. > x <- list(1) > tracemem(x) > # [1] "<0x1149e08f8>" > x[[1]] <- 2 > # (No output) > > Similarly, modifying a list contained in a list doesn't result in a copy: > e <- list(x = list(1)) > tracemem(e$x) >...

Hi, I am using tracemem() to dump some memory contents. When the contents of the memory contain a mix of binary and ascii, the output looks like: 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 2f 79 2e 20 2e 9e 2e fc fe 2e 2e 38 2e 0a 34 38 /y. .........

Hello, I would like for my C function to be able to manipulate some values stored in an R data frame. To achieve this, a need the (real) memory address where the R data frame stores its data (hopefully in a contiguous way). Then, from R, I call the C function and passing this memory address as a parameter. The question: how can we get the memory address of the R data frame? Thank you! L.

Hi Lille, Is it possible you're looking for tracemem() or inspect() ? > x <- data.frame(z = 1:10)> tracemem(x)[1] "<0x55aa743e0bc0>" > x[1] <- 2Ltracemem[0x55aa743e0bc0 -> 0x55aa778f6ad0]: tracemem[0x55aa778f6ad0 -> 0x55aa778f6868]: [<-.data.frame [<- tracemem[0x55aa778f6868 -> 0x55aa778f5b48]: [<-.d...

Gabriel Becker writes: AFAIK R does not automatically copy function arguments. R actually tries very hard to avoid copying while maintaining "pass by value" functionality. ... R only copies data when you modify an object, not when you simply pass it to a function. This is a bit misleading. R tries to avoid copying by maintaining a count of how many references there are to an

Hi all, Where can I find an R binary version (>2.4.0 ) for windows that compiled with R_MEMORY_PROFILING? Within our application we are experiencing serious problems with memory usage. And being able to use "Rprofmem" and "tracemem" command seems like our best option. Thanks, Yoni [[alternative HTML version deleted]]

Hi When I try to update an number in a large data.frame by its pos It's really slow it take almost a sec to do this and I wonder why and if where is any faster way to update a number in a data.frame ive tried DF$col[POS]<-number DF[xPOS,yPOS]<-number Thx //Joel -- View this message in context: http://r.789695.n4.nabble.com/Slow-update-insert-on-Data-frame-tp3055707p3055707.html