Ark: Investigate high memory usage (400mb, 8x RStudio's rsession)

[jmcphers]

System details:

Positron and OS details:

Positron Version: 2024.11.0 (Universal) build 53
Code - OSS Version: 1.93.0
Commit: af3c8088ea323bf347d5bb3ba90bd7c4f51d1b47
Date: 2024-10-16T02:46:52.870Z
Electron: 30.4.0
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.6.0

Interpreter details:

Any R version.

Describe the issue:

The ark process uses a lot of memory.

Steps to reproduce the issue:

Just start Positron with R enabled, then use the operating system's Activity Monitor to check memory usage for the ark process running under Positron. On a cold boot, with no R objects in memory, ark currently uses almost 400mb:

Ark's equivalent in RStudio is rsession. In a comparable environment, it's only 50mb.

Because we start one ark process per R session and it's easy to start several sessions, this can cause Positron to use a lot of memory quickly. We should investigate whether this usage is unavoidable.

Expected or desired behavior:

ark should use less memory, or we should understand why it has to use so much.

[lionel-]

From an Instruments analysis, we've got:

• About 300mb taken up by the virtual document generations for namespaces that don't have srcrefs: Generate virtual documents for namespace functions without source refs ark#251.

  We should investigate whether we need to keep this much memory, we might be leaking unneeded bits. I remember having to deal with leaks through globals managed by the compiler, and we are recompiling functions, so we should keep that in mind. https://github.com/r-lib/memtools might come in handy.

• 2mb allocs for each thread. We should try and reduce them, for instance by using a single tokio executor for the whole process.

• A curious single 64mb alloc in zmq_bind() via getaddrinfo(). It seems a freeaddrinfo() is missing (either due to the way we're calling/managing zmq or because of a bug in zmq).

[lionel-]

A big chunk of that is just from forcing lazy bindings of R packages.

Using:

lapply(rlang::ns_registry_env(), \(x) eapply(x, force))

we see about 100mb just for base packages and rlang.

Note that RStudio is also forcing lazy bindings for entire namespaces when it's looking for completions, so typing base:: forces all base bindings, typing stats:: forces all stats bindings, etc. This quickly increases the baseline memory usage of RStudio after a few minutes of work.

[lionel-]

We currently deparse namespaces for two purposes:

• First, to generate source references for all package functions. This allow step-debugging inside package code "in context" rather than in a single virtual file representing a single function (which is our fallback for edge cases).

• Second, we plan to use these virtual namespace files for static analysis and source code navigation. This is not currently implemented.

One possible plan for fixing this would be:

• Only generate source references when we detect the user is about to debug something. Triggering events could include adding a breakpoint and calling debug(), debugonce() or browser() (we'd inject hooks in these functions).

  Ark would only generate source references at idle time, as is currently the case, but we'd order the list of namespaces to go through so that the namespaces likely to be stepped through would be deparsed first. There's quite a lot of idle time during a debug session so I think that should work out fine. And from the browser() hook we could synchronously deparse the target namespace if not done already, the small delay should not impact the UX too much.

• Rely on downloaded sources for static analysis and source code navigation. See Ark: Debugger: Source missing srcrefs from downloaded tarballs #2286.

With this approach, the increased memory usage would only appear in debug sessions.

(But I think we likely have a leak somewhere that causes inflated memory overhead, we need to investigate this first)

[lionel-]

getaddrinfo

I took a look at the weird 64mb alloc (now 96 last time I looked) in getaddrinfo. I've confirmed that the zmq socket code frees the buffer correctly and is not at fault. I tried to make a reprex by stripping out Ark code but doing so the allocation goes away.

I stopped pursuing this however because I think this is a false positive. This big alloc persists after reducing the total memory usage from 400mb to 110mb and there's just no way that Ark fits in 16mb. Also it does not make sense for getaddrinfo to allocate such a large buffer to begin with.

Thread stack space

I went for the low hanging fruits here and reduced the number of threads created by our Tokio runtimes in posit-dev/ark#720.

A nice benefit of this work is that it's much easier to navigate the threads' call stacks while debugging!

Srcref generation

Generating srcrefs for debugging causes all bindings to be forced as well as some additional overhead. posit-dev/ark#719 makes this lazy by waiting until the user is about to debug a function to generate these srcrefs. Currently only when debug() and debugonce() are called, but we should also do it when a breakpoint is added once breakpoints are supported (#1766).