Default logic change with --replotting-thread-pool-size on CLI

Any chance you’d consider adding a CLI switch or change the default logic to have --replotting-thread-pool-size run with the same priority as --plotting-thread-pool-size does? Something like --replotting-thread-priority could be used but that name may be confusing as its does not have the same logic change as --plotting-thread-priority does.

The use case is now that the app performance is so good at determining optimal default settings, it still requires custom thread settings as to not slow down the farmer once sectors expire on a completed drive and there is still plotting to be done on others.

With the current default settings, when a drive finishes plotting and starts working on expired sectors, its working on those sectors at half the threads that are used for plotting. That is slowing down overall plotting on other drives that have sectors to be finished.

Arguably, the CLI is being used more by farms that are using dedicated machines to farm as fast as possible vs Space Acres being used on less dedicated hardware.

A possible logic option could also be to use the more aggressive replotting thread priority until the sum of all NotPlotted sectors stated on the farmer are zero.

I could be wrong, but it appears sector-encoding-concurrency is not a shared pool that governs replotting-thread-pool-size and plotting-thread-pool-size but rather sets the encoding concurrency for plotting and again for replotting.

If this is the case, setting sector-encoding-concurrency as the max limit for both processes may be more efficient as on a large farm, you want the processor full, but not overloaded.

Average time per sector went from 41 seconds before replotting started (all based on metrcis endpoint data), to 54 seconds after a bit of sectors went AboutToExpire. This is with replotting-thread-pool-size and plotting-thread-pool-size both set to 8 and sector-encoding-concurrency set to 16 on a 128 core system.