OriginalGriff
Мы не можем видеть код йору, поэтому мы понятия не имеем, что именно вы делаете.Скорее всего, из вашего описания следует, что вы запускаете несколько фоновых рабочих и заставляете их всех читать изображение и обрабатывать его.
That won't help, and may make the problem worse. Threading is not a "magic bullet" - it start a new thread which can operate at the same time as your UI thread provided there is a free core to run the new thread. If there isn't, the new thread gets "queued" until a core becomes available. If you create 100 threads, all of them doing a lot of long-time work, yoru system will run out of thread almost immediately, and will get "bogged down" trying to free up memory and access the same disk in each of the threads. once your cores all reach 100% utilization, you are pretty much dead in the water - the system can't magic up extra cores to run more threads, or open more bandwidth to your HDD.
А сама нарезка потоков добавляет накладные расходы, потому что на самом деле управление и переключение потоков занимает процессорное время - опять же на ядре!
Я бы посоветовал вам запустить в два раза меньше потоков, чем у вас есть ядер, и использовать Коллекции concurrentqueue[^] для хранения информации для каждого нового изображения, которое нуждается в обработке. Когда поток завершает изображение, он захватывает следующее из очереди и обрабатывает его. Когда она заканчивается, она закрывается.
Имейте в виду, что отчеты о ходе выполнения также должны быть краткими - если ваши фоновые потоки сообщают о большом прогрессе, это блокирует поток пользовательского интерфейса, а также пытается обрабатывать данные из всех потоков, подающих данные о ходе выполнения.