Positron is copying large objects unnecessarily when working in the console

[joethorley]

System details:

Positron and OS details:

Positron Version: 2025.05.0 (Universal) build 142 Code - OSS Version: 1.99.0 Commit: 17df8dd67df471d39688fc6cd02e3f23543b4d72 Date: 2025-05-05T15:42:05.662Z (3 wks ago) Electron: 34.3.2 Chromium: 132.0.6834.210 Node.js: 20.18.3 V8: 13.2.152.41-electron.0 OS: Darwin arm64 24.4.0

Interpreter details:

R 4.5.0

Describe the issue:

Positron is copying large objects unnecessarily when working in the console

Steps to reproduce the issue:

Consider the following well behaved reprex which only results in the vector of 10 million values being copied once as expected.

library(lobstr)
x <- runif(10^8)
tracemem(x)
#> [1] "<0x300000000>"
y <- x
y[[1]] <- 1
#> tracemem[0x300000000 -> 0x32faf4000]:
y[[1]] <- 1

^{Created on 2025-05-28 with reprex v2.1.1}

But when I execute each line of code one at a time in the Positron console the vector is actually copied twice.

> x <- runif(10^8)
> tracemem(x)
[1] "<0x32faf4000>"
> y <- x
> y[[1]] <- 1
tracemem[0x32faf4000 -> 0x38f0dc000]: 
> y[[1]] <- 1
tracemem[0x38f0dc000 -> 0x300000000]: 

Expected or desired behavior:

The expected and in the case of large objects desired behaviour would for the object to only be copied once when the code is executed line by line in the console in Positron. I note that this behaviour also occurs in RStudio so may be unavoidable but it is certainly unexpected and undesirable.

Were there any error messages in the UI, Output panel, or Developer Tools console?

No

[joethorley]

Interestingly this simplified reprex apparently unnecessarily copies

library(lobstr)
x <- runif(10^8)
tracemem(x)
#> [1] "<0x300000000>"
x[[1]] <- 1
#> tracemem[0x300000000 -> 0x32faf4000]:

^{Created on 2025-05-28 with reprex v2.1.1}

same as when I do it line by line in the Positron R console

> library(lobstr)
> x <- runif(10^8)
> tracemem(x)
[1] "<0x308000000>"
> x[[1]] <- 1
tracemem[0x308000000 -> 0x337af4000]: 

but when I do it line by line in R in the terminal no copying occurs as expected!

R version 4.5.0 (2025-04-11) -- "How About a Twenty-Six"
Copyright (C) 2025 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(lobstr)
> 
> x <- runif(10^8)
> tracemem(x)
[1] "<0x300000000>"
> x[[1]] <- 1

Sorry if I'm just missing something obvious...

[DavisVaughan]

It's almost certainly the Variables pane causing the extra duplication. Something must be bumping the reference count of x while we are inspecting it.

Note that RStudio does have a similar-ish problem, but in general RStudio's behavior is better. RStudio shows you limited information about x when it isn't expanded, and it seems like duplication doesn't occur there.

When you expand x and RStudio starts inspecting the individual values in the vector, then duplication occurs.

For Positron, the first few values are always shown, so it's possible this duplication is impossible to avoid with our current setup, but we should try and track down exactly where in the variables pane the ref count is being bumped before making a decision about this

It is likely related to us tracking current_bindings, where each individual Binding holds an RObject that protected its underlying SEXP, bumping the ref count.

https://github.com/user-attachments/assets/a4206ae4-c6f2-43d4-99fd-b6ffeb7c9884

[jmcphers]

See also https://github.com/posit-dev/positron/issues/507, which tracks the work to make it possible to disable the Variables pane when working with large/sensitive objects.