Блог

Я разрабатываю и поддерживаю в рабочем состоянии инструмент .NET 3.5 и задаюсь вопросом, можно ли получить потенциальный прирост производительности при использовании нового TPL от .NET 4 или даже новых функций async, которые все еще есть в CTP.

Работу инструмента можно грубо описать как:

1. Извлеките список файлов контейнера (в настоящее время .MSI-файлы) — их несколько десятков, ~ 50-70
2. Выполните итерацию по каждому файлу и создайте объект среды выполнения, представляющий его.
3. Для каждого созданного объекта среды выполнения выполните несколько запросов к его содержимому (сравните его содержимое с некоторыми файлами в системе).

Пункты # 2 и # 3 являются длинными, и я хотел бы получить некоторые мнения о возможности увеличения времени выполнения (которое сейчас составляет несколько минут) с помощью Parallel.ForEach или другие методы для параллельного выполнения этой работы.

Потенциальные улучшения, которые я предвижу, заключаются в:

Использование нескольких процессоров / ядер Поддерживает работу приложения во время выполнения операций ввода-вывода (например, чтения файлов) для выполнения чего-то другого.

Как вы думаете, приложения такого типа могут извлечь из этого пользу, прежде чем приступить к разработке?

Это определенно может получить некоторые улучшения при использовании TPL, который теперь доступен в .NET 4.

Все три шага потенциально могут быть спроектированы для параллельного выполнения.

При этом, учитывая вышесказанное, трудно понять, какое улучшение вы увидите. Основная проблема заключается в интенсивном файловом вводе-выводе. Даже если вы воспользуетесь преимуществами нескольких ядер, дисковый ввод-вывод, скорее всего, станет узким местом, и попытка выполнить это параллельно может фактически замедлить выполнение этих частей кода.

Если вы выполняете огромное количество операций ввода-вывода в связи с запросами / вычислениями, то вы можете получить не очень большой выигрыш в производительности, просто запуская подпрограммы параллельно.

Я бы запустил профилировщик, чтобы посмотреть, на что тратит время ваше приложение, а затем принять решение. Если вы обнаружите, что он ожидает завершения ввода-вывода, то вы можете извлечь выгоду из использования модели асинхронного программирования. Если вы обнаружите, что привязаны к вычислениям, то, в зависимости от ожидаемой среды выполнения (многоядерная / одноядерная), вы можете счесть многопоточные вычисления полезными. Конечно, вы можете обнаружить, что применимы оба случая.

Кстати, вы также можете использовать многие функции потоковой обработки .NET 4 в .NET 3.5 с помощью реактивных расширений. В настоящее время я использую это в производительном приложении .NET 3.5.

Как вы думаете, приложения такого типа могут извлечь из этого пользу, прежде чем приступить к разработке?

Не очень много. Вы описываете трехступенчатую систему, в которой каждый этап сильно ограничен вводом-выводом.

Я предполагаю, что у вас есть только 1 диск, это означает, что параллельный запуск может даже замедлить его (больше операций поиска).

С другой стороны, этапы 2) и 3) могут быть достаточно интенсивными для процессора, чтобы увидеть некоторое улучшение.

Вам придется измерять, как обычно.