For large repositories, the hard-coded value of 10 for listPackWorkers significantly reduces the performance of commands like prune.

For example, with a current version of restic (23d7d91) from master working against a 3.2TB repo in an AWS S3 bucket, this prune comand:

restic -p [path] -r s3:s3.amazonaws.com/[bucket] -o s3.connections=128 prune

takes 2.8 hours to build a new index with the default setting of 10 for listPackWorkers from a lightly loaded r4.2xlarge instance. Restic is also unable to take advantage of the increase s3 parallelism that I've given it -- I only see 10-20 simultaneous S3 connections during the run.

With listPackWorkers set to 512, the same index rebuild completes in 11 minutes.

The total runtime of an "empty" prune of this repo, which performs no actual repo changes, drops from 6 hours to 20 minutes with this change. Since prunes lock out the repo, making them run quickly is important if you want to use restic with large repositories.

The optimum value for listPackWorkers will vary based on the size of the machine running restic, the latency to the backend store and the number of concurrent requests that the backend permits, so requiring a recompile to tweak this value is clunky.

I'd recommend making this a configuration option, similar to s3.connections.