Рекурсия vs итерации , на правах Холивара

[Qraizer]

Выделил в отдельную тему, заслуживает. Автоудаление отменено.

[Qraizer]

Цитата Qraizer @ 10.06.22, 18:19

Это было на SSD. Дома проверю на HDD

На HDD разница оказалась лишь количественная, качественно картина та же. Впрочем, фигня это. Понятно, что условия должны быть одинаковы, но предварительный запуск, чтобы одинаковость условий подразумевала кешированность служебных записей тома, ни разу не достоверно отражают реальное положение дел на практике, когда такой кешированности обычно нет.
Поэтому я взял себя в руки и ребутал машину каждый раз. И ждал окончания всех стартовых процедур. Ну, т.е. до прекращения дисковых операций. В итоге рекурсивная версия выдала 114 секунд по разделу с ~20000 файлов *.c (при общем количестве ~615000), нерекурсивный, увы, аж, 172, т.е. в полтора раза медленнее. Надо будет ещё то же с SSD сделать. Но что-то мне подсказывает, что в Win10 дисковый драйвер давно уже оптимизирован именно под рекурсивный обход дерева каталогов. По крайней мере на NTFS, где файловые атрибуты (кроме атрибутов данных разве что) практически всегда лежат в MFT. Просто потому что приложения делают это обычно именно так.

Добавлено 14.06.22, 05:33
P.S. На случай, если вдруг важно, учитывать ли разницу в регистре символов при поиске по маске, можно чуть переделать создание регулярки:

std::regex mask(wildMask, noSens ? std::regex_constants::ECMAScript | std::regex_constants::icase
                                 : std::regex_constants::ECMAScript);

Добавлено 14.06.22, 05:51
P.P.S. Если вдруг надо в ран-тайм определять, различает ли файловая система регистр символов в именах файлов, то тут возникают сложности, т.к. по-хорошему нужно учитывать нюансы локали пользователя, а это отнюдь не однозначная процедура. К примеру, разница между I и i в английском абсолютно не совпадает с таковой в турецком, где есть полный комплект из I, İ, i и ı. Так что я бы рекомендовал сделать предварительно

std::locale::global(std::locale(".utf8"));

Но если можно ограничиться лишь стандартным комплектом символов, то что-то типа:

  fs::path tempName1(fs::temp_directory_path() / "CheckCaseSens"s),
           tempName2(fs::temp_directory_path() / "checkcasesens"s);
  std::ofstream(tempName1, std::ios::ate);
  std::ofstream(tempName2, std::ios::ate);
  bool isNoCaseSens = fs::equivalent(tempName1, tempName2);
 
  fs::remove(tempName1);
  if (!isNoCaseSens) fs::remove(tempName2);

должно помочь. Поосторожнее только с последними двумя строчками.

Добавлено 14.06.22, 05:56

Цитата mkudritsky @ 11.06.22, 01:47

Ясное дело, что тип char** не подойдет, так как непонятно - как эффективно выделять память для разного количества файлов?

Запросто подойдёт. Как и для любого динамически изменяющего свой размер массива, realloc() прекрасно умеет увеличивать размер массива указателей, если есть на это память, конечно. Другое дело, что это будет уже не список, но по факту массив указателей будет эффективней списка указателей. В отличие от массива std::string, который очень вряд ли будет эффективней списка std::string.

[Qraizer]

Цитата Qraizer @ 14.06.22, 05:29

Надо будет ещё то же с SSD сделать.

Сделал. То же самое, как и ожидалось. Так что скорость дисковой подсистемы в общем-то влияет, конечно, но не качественно. Механизмы оптимизации размещения служебной информации на томе влияют куда сильнее. Допускаю, что на каком-нибудь FAT или ext4 будут совсем другие цифры. (Если у кого под рукой есть никсы, потестите, плз.)

P.S. На томе SSD его вышеупомянутые 50000 файлов отбирались из общего количества без малого 765000.