Indeed, I think we should remove the service and use auto-optimise-store instead.

Do we have control over when auto-optimise-store runs? If not, I would say we keep the scheduled option in.

From the manual:

If set to true, Nix automatically detects files in the store that have identical contents, and replaces them with hard links to a single copy. This saves disk space. If set to false (the default), you can still run nix-store --optimise to get rid of duplicate files.

I am pretty sure the optimisation is done when creating a store path.

My operational practice is to auto-optimize iff the store is on a SSD. (and no other optimize)

On a rotating drive the savings tend not to be worth the price, regardless of doing the dedup online or offline, and on an SSD the price of auto-optimize seems negligible.

The overhead I'm (sometimes) interested in isn't in CPU but in disk IO. I think the constant queries into the huge /nix/store/.links/ directory was the cause of that major slow-down I experienced. (One probe per new file in nix store, and unlink and link op.) EDIT: this may depend on the FS used, as having so many files inside a single directory isn't a norm; stratifying it might help (think .git/objects/).

This particular PR has no negative effects and the discussion concerning disabling scheduled optimisations looks like it needs to be had separately from this.

Does anybody have any specific concerns about this change? If not, we should go ahead and merge this and we can always rip out the scheduled option at a later stage.

Right, go ahead.