I'm planning on implementing persistence in the near future, likely using some kind of generic embedded database or KV store rather than a serialization format. The primary goal would be to enable resummarization without rescanning directories and consequently, real-time updates from file notifications. However, I don't want to force persistence, since one use case for this tool is answering "why is my laptop hard drive completely full!?!?".
re: memory usage, because of the price of RAM these days, my original plan was for a hierarchical memory usage analyzer, but attribution of shared libraries on Linux isn't straightforward.
"Real" memory usage is unfortunately ill-defined since it could mean "memory freed by killing a process", "memory allocated specifically to the process", "proportional of system memory shared by other processes", etc.
Such a tool would likely need multiple subcommands to reflect how the user's intent, along with an extensive README to explain the subtleties.
To illustrate, if we only show the proportional set size in a hierarchy (e.g. IDE with LSP... I'm looking at you rust-analyzer!), but the user wants to know how much memory could be reclaimed by killing the parent process, two things could happen, as far as I understand. If it's the only hierarchy using a large chunk of shared libraries, the PSS will be pretty close. However, if other apps are using those libraries, very little memory will be freed (mostly what was allocated specifically to the killed app).
On top of that, we also have to consider swap space.
I may revisit this in the future once I have a better understanding of smaps and friends, if RAM prices don't normalize anytime soon.
I had been exploring using an embedded database as an index, but for my current use case, waiting just under a minute to rescan my /nix/store on a weak mini-pc is acceptable.
Also looking to add inotify integration, which would require an index to accurately update the visualization.
Thanks! I'll need to check out SpaceSniffer next time I'm on Windows.
Can you provide some examples of "quick actions"?
Currently, the visualization is purely based on file sizes in the directory structure. Package management adds some complications beyond the fact that there are at least a dozen popular managers in the wild. For one, package dependencies form a directed graph rather than a hierarchical tree, so credit assignment is vague. Two packages can depend on the same two dependencies. Do we give full credit to both, one or assign partial credit? Would we weight partial credit evenly or by dependent size or some external factor/
re: memory usage, because of the price of RAM these days, my original plan was for a hierarchical memory usage analyzer, but attribution of shared libraries on Linux isn't straightforward.
"Real" memory usage is unfortunately ill-defined since it could mean "memory freed by killing a process", "memory allocated specifically to the process", "proportional of system memory shared by other processes", etc.
Such a tool would likely need multiple subcommands to reflect how the user's intent, along with an extensive README to explain the subtleties.
To illustrate, if we only show the proportional set size in a hierarchy (e.g. IDE with LSP... I'm looking at you rust-analyzer!), but the user wants to know how much memory could be reclaimed by killing the parent process, two things could happen, as far as I understand. If it's the only hierarchy using a large chunk of shared libraries, the PSS will be pretty close. However, if other apps are using those libraries, very little memory will be freed (mostly what was allocated specifically to the killed app).
On top of that, we also have to consider swap space.
I may revisit this in the future once I have a better understanding of smaps and friends, if RAM prices don't normalize anytime soon.