я бы посмотрел на такую функцию

У меня есть проблема в проекте. Нужно под Windows окружением определять размеры каталогов на кластерном файловом хранилище удаленно, но в пределах LAN (протокол SMB/Ethernet). Проблема в том, что скорость рекурсивного обхода каталога при использовании FindFirst/FindNextFile оставляет желать лучшего, если в каталоге довольно много (сотни тысяч) файлов/каталогов и (не)приличная глубина вложенности. Если полазить по всяким stackoverflow , то можно выяснить, что для Windows якобы ничего более производительного, чем использование указанных API функций, нет. Причем у этих функций есть Ex варианты , в которых можно указать ряд оптимизирующих флагов. Пробовал - мало толку, потому что все равно остается еще много лишнего мусора, который ОС тащит из NTFS. При этом не спасает даже то, что сам исследуемый каталог может находиться на суровом enterprise JBOD/RAID из SSD дисков.

Была идея вынести рассчеты на локальный уровень посредством служб(ы), чтобы избежать overhead'a SMB протокола. Это реально дает прирост производительности, но все равно, не настолько насколько хотелось бы. А хотелось бы приблизиться к производительности Windows Explorer и идеале обойти его.

В целом, если сравнивать мою наивную реализацию на FindFirst/FindNextFile и ту реализацию, которая используется в Explorer'e (открыть каталог, правой кнопкой мыши, посмотреть свойства), то создается впечатление, что Проводник не использует FindFirst/NextFile API, либо использует их как-то очень хитро, потому что производительность его рассчетов значительно превышает производительность указанных функций в моей реализации (проводил как-то анализ на "холодных" данных/кэше).

Подозреваю, что придется нырнуть ближе к ядру и MFT, благо в MSDN много чего описано на этот счет, но пока руки не доходят...

Если у кого есть подобный опыт, делитесь, будет интересно :)

может CRTP?

может и покажу, но пока нет особо времени на адаптацию кода.
выкладывать вариант, который никто потестить не сможет, не вижу смысла

но сразу скажу, что там нет ничего сверхестественного, все довольно примитивно:
обходим каталоги, строим полный путь складывая имена каталогов с предыдущими сегментами путей, извлекаем размер файлов, накапливаем их в total size переменную. Все в рамках WinAPI, выше головы, как говорится, не прыгнешь