-
Notifications
You must be signed in to change notification settings - Fork 237
Memory Usage
Unison uses memory during operations, of course. For any amount of RAM, swap, etc., unison will run out of memory for some workload. The questions are thus:
- is there a bug, where memory that clearly should have been freed is not?
- is the amount used to represent the needed state higher than it could be, in some clear, fixable way?
Unison reads the entire state of a sync into memory. This uses about 730 bytes per file (on a 64-bit CPU type), as of 2.53.7 in 2025-01. At this level, this is "working as designed" and not a bug.
OCaml stores values in a machine word. Thus, on a 32-bit CPU, that's 32 bits, and on a 64-bit CPU, that's 64. Note that many hardware implementations can run into multiple modes, so it's really a question of whether x86_64-capable hardware is run in i386 or x86_64 mode, or aarch64-capable hardware (e.g. Raspberry Pi 3) is run in earmv7 or aarch64 mode. (The same could be said for sparc and sparc64, to avoid leaving out retrocomputing folks!)
One could design and implement a scheme where the archive state is read from disk as needed, rather than read all at once. This is really an application-specific version of virtual memory, and it is likely to be significant work and has a high likelihood of bugs. Thus, it is unlikely that anyone would implement it, and it is unclear if it would be merged.