That’s not the case: The scanner is still run (it used to be disabled back in 0.8.0 when backup would wait until the scan has finished)
I did not receive any reports that disabling verbose output (or the scanner) improves memory consumption. Is there something I’m missing?
That’s the case, and this can contribute to high memory usage. However, I observed that memory usage is proportional to the number of blobs (parts of files) in the repo. If you have a few very large files, restic will split these into large blobs, so the repo won’t have so many blobs. On the other hand, when you have many small files you’ll end up with many bobs (at least one per file), and this tends to use a lot of memory. I suspect the index data structure restic holds in memory may be the cause, this is something different than the index/ files in the repo.
I’m not sure this is the case, where did you see that? Sure, the strings used for displaying the status information doesn’t need to be garbage collected after use, so it can somewhat reduce the memory usage, but I doubt it makes a dent in the overall memory usage…
Indeed, restic’s scanner doesn’t care about hard links, so for a 100MiB file which has a hard link in the backup target it’ll report 200MiB to do.