Размер MFT против парсинга MFT
Я работаю в проекте, где я должен перечислить имена файлов с диска. Я попробовал два метода
- Разбор MFT и
- Многопоточность с FindFirstFile. Я сравнил время выполнения обеих реализаций, и он показывает меньший размер MFT, более быстрое его выполнение, и если размер MFT больше, чем ГБ, выполнение занимает больше времени.
Мои наблюдения:
- Том C: MFT. Размер: 1,85 ГБ. Время выполнения: 65 с. Количество ядер: 9 с.
- Том D: MFT. Размер: 38 МБ. Время выполнения: 0,593 с. Количество ядер: 1 с.
- Объем C: MFT Размер: 1,02 ГБ. Время выполнения: 11 с. Количество ядер: 3 с.
- Том D: MFT. Размер: 89,75 МБ. Время выполнения: 1 с. Количество ядер: 2 с.
P.s Измерения взяты из двух отдельных машин.
С этими наблюдениями меня немного смущает, зависит ли разбор MFT от его размера? Почему многопоточность не обеспечивает лучшее решение для MFT меньшего размера?
Решение
Многопоточность с FindFirstFile вряд ли предоставит вам какую-либо выгоду. Если у вас есть два отдельных потока, идущих за одним и тем же физическим диском, вы будете вынуждены искать ненужные заголовки дисков, что будет означать больше времени для выполнения чтения, что вполне может привести к многопоточной версии с использованием FindFirstFile а также FindNextFile быть помедленнее чем однопоточная версия.
Ходьба MFT потенциально может быть быстрее, чем использование FindFirst / FindNext, но за счет довольно большой дополнительной работы. И, если у вас нет специальных знаний о диске, вероятно, не будет быстрее довольно оправдать расходы на написание кода для работы на этом более низком уровне. И вполне вероятно, будет медленнее в общем случае. Я подозреваю, что разработчики NTFS и те, кто написал FindFirstFile / FindNextFile, знают кое-что о MFT, чего большинство из нас не знает, в том числе о том, как эффективно его выполнять.
Другие решения
Других решений пока нет …