bundle:mem doesn't seem to be deterministic - is this expected?

[timdiggins]

When I run bundle exec derailed bundle:mem I expect that it's doing static analysis of my requirements and just adding up memory usage.

However when I run it repeatedly it seems to be returning different amounts for both the total and each Gem.
This seems unexpected to me, but is this a known behaviour?

The variance currently is more within an individual commit than across commits (which I'm pretty sure have increased my memory consumption).

╰─ bundle exec derailed bundle:mem | head -n 2                                                                                                                               ─╯
TOP: 144.6758 MiB
  rails/all: 65.2031 MiB
╰─ bundle exec derailed bundle:mem | head -n 2                                                                                                                               ─╯
TOP: 146.957 MiB
  rails/all: 64.9805 MiB
╰─ bundle exec derailed bundle:mem | head -n 2                                                                                                                               ─╯
TOP: 149.8164 MiB
  rails/all: 73.7383 MiB
╰─ bundle exec derailed bundle:mem | head -n 2                                                                                                                               ─╯
TOP: 153.6094 MiB
  rails/all: 71.082 MiB
╰─ bundle exec derailed bundle:mem | head -n 2                                                                                                                               ─╯
TOP: 142.4922 MiB
  rails/all: 66.2813 MiB

[schneems]

Booting a rails app isn’t deterministic. There’s randomized state (like random seeds) and dynamic state (like date/time) even the order files are loaded might not be deterministic. Then you get into how Ruby allocates memory where if it needs one byte more than it has, it will ask for x% more memory instead of just one byte. Then you’ve got OS non determinism. Just because you ask for X amount of memory doesn’t guarantee the OS will give it to you right this second.

Now you start adding in things like bootsnap that caches state between process execution and other gems that monkeypatch core method (like derailed). When you add up all those tiny variations you’re essentially guaranteed to NOT have a deterministic memory measure. You can get a ballpark but not exact.