Файлы на XP: Безопасно ли отключать «время последнего доступа»?

Question

Я отчаянно ищу дешевые способы сократить время сборки на моем домашнем ПК. Я только что прочитал статью об отключении атрибута Last Access Time файла в Windows XP, чтобы простые операции чтения ничего не записывали на диск.

Это тоже очень просто. При DOS-подсказке напишите:

fsutil behavior set disablelastaccess 1

Кто-нибудь когда-нибудь пробовал это в контексте создания проектов C ++ ? Есть ли недостатки?

[Редактировать] Подробнее по теме здесь .

Answer 1

Из документации SetFileTime :

«NTFS задерживает обновление до последнего времени доступа к файлу до одного часа после последнего доступа.»

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

EDIT:

Относительно того, почему автор этой статьи заявил о 10-кратном ускорении, я думаю, что он объяснил свое ускорение неправильной вещью: он также отключил 8.3 генерацию имени файла. Чтобы сгенерировать имя файла 8.3 для файла, NTFS должна в основном генерировать каждую возможность по очереди, а затем посмотреть, используется ли она уже (без ссылки; я уверен, что Raymond говорил об этом, но не может найти ссылка на сайт). Если все ваши файлы имеют одни и те же первые шесть символов, вы будете укушены этой проблемой, и, как следствие, вы должны поместить символы, которые отличают файлы в первые шесть символов, чтобы они не конфликтовали. Отключение генерации короткого имени предотвратит это.

Answer 2

Я бы посоветовал вам попробовать и посмотреть, будет ли это иметь значение.

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

Хотелось бы, чтобы меня ошиблись.

---

Результаты:

Выполнил несколько сборок на основе кода на работе как в конфигурации отладки, так и в конфигурации выпуска с последним включенным временем доступа и отключенным.

Наш исходный код составляет около 39 МБ (48 МБ на диске), и мы собираем около половины этого для конфигурации, которую я создал для этих тестов. Отладочная сборка сгенерировала 1,76 ГБ временных и выходных файлов, в то время как выпуск сгенерировал около 600 МБ таких данных. Мы строим из командной строки, используя комбинацию Ant и встроенных инструментов командной строки Visual Studio.

Моя машина - Core 2 Duo 3GHz, 4 ГБ оперативной памяти, жесткий диск 7200 об / мин, 32-разрядная ОС Windows XP.

Здание с отключенным последним временем доступа:

Время отладки = 6:17, 5: 41

Время выпуска = 6:07, 6: 06

Здание с включенным последним временем доступа:

Время отладки = 6:00, 5: 47

Время выпуска = 6:19, 5: 48

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

Я полагаю, что вы получите наибольшую отдачу от вложенных средств, просто внедрив надлежащие предварительно скомпилированные заголовки (а не автоматически сгенерированные заголовки, которые Visual Studio создает в проекте). Мы реализовали это несколько лет назад на работе (когда база кода была намного меньше), и это сократило наше время сборки до трети того, что было.

Answer 3

Я не пробовал это на коробке с Windows (буду сегодня вечером, спасибо), но подобное в Linux (опция noatime при монтаже диска) ускорило процесс значительно .

Я не могу придумать каких-либо применений, где время последнего доступа было бы полезно, кроме как для целей аудита, и даже в этом случае Windows хранит пользователя, который обращался к нему? Я знаю, что Linux нет.

Answer 4

Это хорошая альтернатива, но она повлияет на некоторые инструменты. Как и служба удаленного хранения, и другие утилиты, которые зависят от статистики доступа к файлам для оптимизации вашей файловой системы (например, Norton Defrag)

Answer 5

Майку Диммику:

Попробуйте подключить USB-накопитель со многими файлами и скопировать их на свой внутренний накопитель. Это также относится и к компиляции программы (которая описана в оригинальном сообщении).

Answer 6

Отключение времени доступа полезно при использовании ssd (твердотельных накопителей - карт, USB-накопителей и т. Д.), Поскольку оно уменьшает количество операций записи на диск. Срок службы всех твердотельных запоминающих устройств измеряется количеством записей, которые можно выполнить для каждого отдельного адреса. Некоторые СМИ указывают минимум 100 тысяч, а некоторые даже 1 миллион. Операционные системы и другие исполняемые файлы могут обращаться ко многим файлам за одну операцию, а также к документам пользователя. Это будет относиться к Eee PC, встроенным системам и др.

Answer 7

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

Тем не менее, если вы хотите улучшить время сборки проекта C ++, я настоятельно рекомендую прочитать Рекурсивное создание считается вредным . Этой статье уже около десяти лет, но ее смысл в том, что рекурсивные определения в наших сценариях сборки приводят к длительным временам сборки, все еще стоит понять.

Answer 8

Я не хочу отвлекать внимание от вопроса о «последнем времени доступа», но могут быть и другие способы ускорить ваши сборки. Не зная контекста и настроек вашего проекта, трудно сказать, что может быть медленным, но могут быть некоторые вещи, которые могут помочь:

Создание "убер" сборок. То есть создайте один файл uber.cpp для компиляции, содержащий несколько строк, например

#include "file1.cpp"
#include "file2.cpp"

У вас могут быть проблемы с конфликтующими именами статических переменных, но их, как правило, легко разобрать. Первоначальная настройка является своего рода болью, но время сборки может значительно увеличиться. Для нас самым большим недостатком является то, что в студии разработчика нельзя щелкнуть правой кнопкой мыши файл и сказать «скомпилировать», если этот файл является частью сборки uber. Это не имеет большого значения, хотя. У нас есть отдельные конфигурации для сборок 'uber', которые компилируют файлы uber, но исключают отдельные файлы cpp из процесса сборки. Если вам нужна дополнительная информация, оставьте комментарий, и я могу получить это. Кроме того, оптимизатор, как правило, работает немного лучше с Uber-сборками.

Кроме того, у вас есть большое количество включаемых файлов или много зависимостей между включаемыми файлами? Если это так, это значительно замедлит время сборки.

Используете ли вы предварительно скомпилированные заголовки? Если нет, вы можете посмотреть на это как на решение, так как это также поможет.

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

В любом случае, извините, что немного расстроил тему, но предложение изменить время последнего доступа к файлу казалось чем-то вроде решения «кувалды».

Answer 9

это немного улучшит производительность. Кроме этого, он не будет делать намного больше (конечно, вы не сможете увидеть, когда к файлу последний раз обращались). У меня он выключен по умолчанию, когда я устанавливаю Windows XP, используя nLite , чтобы избавиться от ненужного раздувания.