Windows и Office: новости и советы
| N 64 Здравствуйте, уважаемые подписчики. |
ConservativeSwapfileUsage=1 |
| Этот параметр был документирован
некоторое время спустя после выхода Windows 98. В описании к нему сказано, что он предназначен для обеспечения совместимости с некоторыми программами для Windows 95, которые отслеживают обращения Windows к файлу подкачки. Внутренний механизм работы с файлом подкачки в Windows 98 изменен. При необходимости выгрузки какой-либо области памяти в файл подкачки Windows 95 ждала момента, когда система в целом оказывалась в состоянии простоя, а Windows 98 ждет момента, когда простаивает VFAT, то есть лишь одна из подсистем - дисковая. Такой подход должен повышать быстродействие системы. На практике повышение оказывается практически незаметным из-за относительной редкости операций записи в файл подкачки. К тому же дополнительное условие для заметности - высокая загруженность процессора при невысокой интенсивности обращений к дискам, что встречается не так уж часто. Впрочем, как заявлял герой одного анекдота, "десять старушек - уже рубль". И именно набор таких небольших выигрышей приводит к тому, что быстродействие новых систем (подчеркну: при прочих равных условиях) оказывается выше, чем у старых. В предвидении возмущенных писем с утверждениями, что Win95 всегда работает быстрее, чем Win98, напомню один факт. ZDNet, которая отнюдь не с симпатией относится к "Майкрософт", в 1998 году обнародовала результаты своих исследований. Согласно им, при 16 МБ ОЗУ связка Win95+IE4 работает быстрее, чем Win98. При 32 МБ Win98 оказывается на 9 процентов быстрее своей предшественницы. С ростом объема памяти выигрыш увеличивается, хотя уже и не так быстро. Но вернемся к нашим баранам. Помимо документированного эффекта параметр ConservativeSwapfileUsage=1 обладает еще недокументированным. Он также включает использование алгоритма управления файла подкачки от Windows 95. То есть отменяет предварительное увеличение размера файла подкачки и выгрузку в файл подкачки неиспользуемых модулей ради увеличения размера дискового кэша. Народная молва, заметив это, тут же приписала ему чудодейственный эффект: якобы, параметр заставляет Windows максимально эффективно использовать оперативную память, минимизируя использование файла подкачки. Внешне объяснение действительно логичное: если у вас 128 МБ памяти, то после загрузки, хоть несколько десятков мегабайт физической памяти и свободно, Windows 98 создает файл подкачки в 20-30 МБ. А если добавить в файл system.ini упомянутый параметр, то размер файла подкачки оказывается нулевым. Казалось бы, уменьшение подкачки налицо? В том то и дело, что нет. Подкачки не было и в первом случае (системный монитор показывает, что занято в файле подкачки 0 байт). Но кому нужно запускать системный монитор и разбираться в его показаниях? А команда DIR, такая простая и наглядная, всегда под руками.
|
Эксперимент |
| Так что же в действительности дает этот
параметр? Я решил выяснить это экспериментально. Но чем измерять?
Имеющаяся у меня версия WinStone уж очень старая и нормально на Windows 98
работать не хочет. SiSoft Sandra и схожая программа из NU не годятся,
поскольку не _измеряют_ быстродействие компьютера, а _оценивают_ его. Они
меряют отдельные характеристики, каждую независимо от других, а потом, по
каким-то своим соображениям, выводят итоговое значение. В результате
получаем некое конкретное число, но на него можно только ориентироваться. Я выбрал в качестве тестового задания печать большого документа Word (30 МБ, свыше 400 страниц) со множеством рисунков и таблиц. Word запускался командой печати данного документа, после чего автоматически закрывался. В свойствах принтера была включена отложенная печать, так что собственно печать документа не выполнялась, а только формировались данные для печати. Сама процедура эксперимента выглядела так. Использовалась рабочая копия
Win98SE на машине следующей конфигурации: Пентиум III 667 МГц, 128 МБ ОЗУ,
винчестер 7200 об/мин с двухмегабайтным кэшем. Настройки виртуальной
памяти и кэша - принятые по умолчанию. Такая пара экспериментов была для накопления статистики повторена трижды. Затем то же самое я проделал для памяти, ограниченной размером 48 МБ. Параметры системы измерялись системным монитором, включенным на запись данных в файл. Периодичность замеров была задана равной 0,1 секунды. Итого - 12 перезагрузок и 12 тестов.
|
Результат |
| Прежде всего, меня удивило то, что во
всех 12 случаях после печати размер файла подкачки был одинаков: 19
четырехмегабайтовых кусков. Логично было бы ожидать, что при меньшем
объеме памяти файл подкачки должен был бы быть больше. Добавление параметра действительно уменьшало исходный размер файла подкачки: с 68 МБ до 0 при 128 МБ памяти и с 68 МБ до 52 МБ - при 48 МБ ОЗУ. При 128 МБ занято в файле подкачки перед началом печати (т.е. после загрузки) в обоих случаях было 0 байт, при 48 МБ - около 2 МБ при выключенном и 0 - при включенном параметре. Напомню, что сразу после выполнения задания размер файла подкачки был одинаков во всех 12 экспериментах. То есть, место на диске добавлением этого параметра сэкономить не удалось. А как обстоят дела с другими характеристиками, в частности, собственно
объемом подкачки и скоростью? Ведь чем меньше обращений к файлу подкачки,
тем выше должна быть скорость работы.
У двух параметров разница была статистически достоверной. При ОЗУ 48 МБ добавление параметра ConservativeSwapfileUsage=1 увеличивало количество выгрузок страниц в файл подкачки с полутора тысяч до ~1800 при разбросе внутри серий всего около процента. При этом уменьшалось, также примерно на 300, число очищенных страниц, то есть количество страниц, которые могут быть высвобождены без записи их содержимого в виртуальную память. Говоря проще, добавление этого параметра увеличивало число случаев,
когда содержимое памяти перед выделением другому модулю необходимо было
выгрузить в файл подкачки. Согласитесь, что о такой ситуации трудно
сказать, как об улучшении использования имеющейся оперативной памяти.
Скорее, наоборот. |
Обсуждение результатов |
| Возможно, вы оцените результаты
эксперимента иначе (был бы рад услышать аргументированные возражения), но,
на мой взгляд, они практически полностью подтверждают заявления
разработчиков (см. предыдущий выпуск рассылки). Одинаковое значение размера файла подкачки в конце работы показывает, что потребность системы в виртуальной памяти не зависит от параметра. Выделяется ли память _до_ запуска программы или после - влияет только на _первоначальный_ размер файла подкачки. Количество необходимой системе виртуальной памяти не меняется. То, что размер файла подкачки оказывается одинаковым и при 128 МБ ОЗУ, и при 48 МБ, вероятно (гарантировать правильность вывода не стану), означает, что общее количество места, зарезервированного в файле подкачки (как до запуска программ, так и в процессе работы), зависит от запущенных программ, а вовсе не от объема ОЗУ. Это опять-таки соответствует логике использования файла подкачки, изложенной разработчиками.
|
Дополнительный эксперимент |
| Когда выпуск рассылки был уже почти
готов, я задумался над увеличением количества выгрузок страниц в файл
подкачки. А что, если это увеличение является "одноразовым" и в дальнейшей
работе не проявляется? Впрочем, это легко проверить. Поскольку в данном случае вполне достаточно качественной картины, без тщательных измерений можно было обойтись. Описанный выше эксперимент был проделан еще два раза, оба раза при 48 МБ, один раз с выключенным параметром, второй раз - с включенным. На этот раз печать выполнялась дважды. Между операциями печати была сделана небольшая пауза, чтобы в протоколе системного монитора можно было легко отличить одну операцию от другой. Результат: при отключенном параметре выгрузка страниц в файл подкачки происходила только во время первой печати. При включенном параметре - и во время первой печати, и во время второй. Правда, при второй печати интенсивность выгрузки была в несколько раз меньшей, но все же достаточно заметной. Мое предположение оказалось неверным.
|
Вывод |
| Добавление параметра
ConservativeSwapfileUsage=1 в раздел [386Enh] файла system.ini приводит к
уменьшению размера файла подкачки перед началом объемной работы или через
некоторое время после нее, не влияет (или мало влияет) на размер файла
подкачки во время работы, не оказывает заметного влияния на скорость
работы, приводит к более интенсивному использованию виртуальной памяти. В целом, изменения, внесенные в Windows 98 в алгоритм работы с виртуальной памятью, как и утверждают разработчики (см. предыдущий выпуск), улучшают работу системы с этой памятью. А как же быть с множеством случаев, когда при добавлении этого параметра наблюдалось улучшение работы системы? Увы, могу объяснить это только эффектом плацебо. Тем более что во всех известных мне таких случаях оценка производилась на глаз, без каких-либо измерений. Подобным оценкам принято доверять только при сравнении двойным слепым методом. Приведу пример влияния субъективности из моего личного опыта. Небезызвестный в англоязычном Интернете Эндрю Кэмерон писал мне по поводу Win2cache: "The log file says 'not installed' - however I am SURE it is, because things seem A LOT faster". И это при том, что программа не только не установилась, но и в принципе не могла дать никакого улучшения на PIII. Налицо обычное самовнушение, когда ожидаемое воспринимается как происходящее в действительности.
|
| Так вреден или полезен параметр
ConservativeSwapfileUsage=1?
Я не стану давать категорического ответа. Конечно, его добавление ухудшает параметры системы, но ухудшение не настолько велико, чтобы быть критически важным. С другой стороны, Windows 9x/Me - это _персональная_ ОС, и настраивать ее следует так, как удобнее и приятнее вам. Если вам кажется, что при добавлении параметра система работает быстрее, и вам при такой настройке работать комфортнее - добавление необходимо. В конце концов, существуют люди, которые оценивают скорость не по скорости работы приложений, а по тому, насколько быстро выскакивают окошки или насколько быстро система загружается. Каждый вправе настраивать свою систему так, как нравится именно ему.
Вот только навязывать свои предпочтения другим, если эти предпочтения не
подкреплены фактами, не стоит. |
Игорь Лейко |
| http://subscribe.ru/
E-mail: ask@subscribe.ru | Отписаться | Relayed by Corbina
Рейтингуется SpyLog |
| В избранное | ||
