VladD2 wrote:
> C>"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге
> C>Windows: 1241 папок и 11163 файлов.
> Серьезно? Ну, тогда перестать *мошейничать* и убери опцию "/Q". Сразу
> станет пошустрее. У меня в виндовс 23К файлов и тест отрабатывает
> быстрее чем за секунду (когда информация закэширована). На ноуте где-то
> 17К файлов и тоже меньше секунды.
BJam внутри делает проверку, что файл можно открыть — это примерно
аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие
файла на проверку ACLей).
Не веришь — смотри файл headers.c и hcache.c из исходников BJam.
> Ни одна система сборки проектов не занимается фигней вроде сбора
> информации о владельцах файлов. И уж темболее не будет превращать все
> это в текст и записывать в файл.
Вывод в текстовом файл — копейки по времени.
> C>На разбросаных по всей FS include-файлах, половина которых evict'ится из
> C>кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS.
> У тебя же была инкрементальная компиляция? Поди еще и прекомпилируемые
> заголовки включены? Как же выходит, что нужно читать все иклюды?
А как еще определить,
что именно нужно перекомпилировать?
Например, если я поменяю файл boost/filesystem/fstream.hpp, то нужно
будет перестроить половину проектов (включая и подключенный
boost::filesystem).
Posted via RSDN NNTP Server 2.0