Give pantsd more RAM by default.

[benjyw]

1GiB turns out to be too low for even medium-sized repos. Several users have remarked on this on Slack (search for "pantsd_max_memory_usage" there to see those), and we've noticed it in the Toolchain repo.

Most developer laptops have plenty of RAM. So 4GiB seems like a decent default.

[jsirois]

I find this terrifying. Do we have any handles on this at all? Something like lines of code times X -> Y ram?

[benjyw]

We don't have a handle on this, as far as I know, and I imagine it will be some function of number of source files (rather than LoC) and which plugins you've enabled.

That said, this is a maximum, so you'll only actually use that much RAM if you need it, in which case you probably want to use it?

[jsirois]

Yes, the user wants it if they need it. The issue is we put them in that situation and the situation is seemingly ridiculous on its face. That's my concern, that we have no handle on this.

[kaos]

well yea.. that's an absurd amount of memory.. 🤔

[benjyw]

Yeah, I have no idea what takes up all this memory. I assume it's mostly memoized rule invocations, but we'd have to measure to find out and potentially reduce. Maybe @stuhood has some intuitions here.

[sureshjoshi]

Does the daemon release memory after usage, or only when it's killed/restarted? For example, I have a couple daemon's sitting around, each at 500MB. I'm sure the system would kill/purge/page them if it needed to recoup, but does the daemon do that on its own?

My policy during dev is, use all my memory while you're building/whatever (looking at you Android/Gradle), but then release most of it back.

[benjyw]

I believe only when it's killed.

[stuhood]

pantsd will hold 1 version of each Node at a time in memory, but it will currently never actually free a Node: so if you build A, and then switch to building B, a copy of A will stick around until the next restart. That issue is covered by #7675.

Yeah, I have no idea what takes up all this memory. I assume it's mostly memoized rule invocations, but we'd have to measure to find out and potentially reduce. Maybe @stuhood has some intuitions here.

As mentioned in the thread where this was last discussed: if users are seeing abnormal amounts of memory used, opening tickets with --stats-memory-usage output attached would be helpful. It reports which objects are using the most memory, including both the Python and Rust memory usage of Nodes.