@MSGID: 2:5020/828.777 68051a08
@REPLY: 2:5000/14 6804aab4
@PID: GED+W32 1.1.5-b20240306
@CHRS: CP866 2
@TZUTC: 0400
@TID: hpt/w32-mvcdll 1.4.0-sta 16-02-06
Здpавствуй, Eugene!

 MS>> пользовательское ПО так устроено, что изначально использует ее
 MS>> экстенсивно.

 EM> Правильнее будет сказать "современное ПО", ибо изрядная часть
 EM> системного уже давно пишется примерно с тем же уровнем квалификации,
 EM> что и чисто пользовательское.

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

 MS>> когда неиспользуемые процессы выносятся системой подальше от ЦП И
 MS>> ОЗУ в медленный файл подкачки

 EM> По правилам, они не должны никуда выноситься до тех пор, пока не
 EM> возникнет дефицит памяти - или реальный, или с высокой вероятностью
 EM> приближающийся.

  Именно так, пока не. Hа вопрос "Зачем ей столько памяти?" есть
простой ответ. ОС-то 64-разрядная. Она более масштабируемая, плюс с
установленными 64-разрядными программами, которые занимают больше памяти в ОЗУ, чем
программы x86. Такая вот система с повышенными требованиями к ОЗУ.

 Остается открытым вопрос, зачем трогать настройки управления
виртуальной памятью, которые выбираются оптимальными по-умолчанию.

 Мнение, что файл подкачки на SSD - плохо, просто какой-то миф. Вот
что действительно важно - это проверить поддерживает ли TRIM та версия
Windows 7.

fsutil behavior query disabledeletenotify

Если 0, то TRIM включен для SSD и держать на нем файл подкачки и можно и нужно.

 MS>> там очень вероятно обнаружится, что программистам этого тоссера
 MS>> для ускорения его работы было быстрее считать файлы в виртуальную
 MS>> память целиком

 EM> Да, есть такое. А ты в курсе, _как_именно_ работает это считывание,
 EM> или так, мимо проходил? :)

  В общих чертах. И это предположение, что в коде такое может быть.
Тоссер же старый? Старый. 32-разрядный. Hу вот Чеславу и глюки.

 MS>> для них было главное, что считать файлы целиком в виртуальную
 MS>> память было _быстрее_.

 EM> Тут надо бы оговориться, что "быстрее" - это прежде всего для
 EM> программиста в плане написания программы, а не для системы в плане ее
 EM> выполнения.

 Все же это не имеет отношения плохому программированию. Memory-mapped
I/O действительно и быстрее, и эффективнее, чем обычные чтение и запись.

 MS>> А теперь представь, что у тебя имеются на диске 30 Гб фотографий
 MS>> и видео и есть некая программа для их просмотра, с функцией
 MS>> кеширования. А почему бы ей, этой программе, не считать тогда все
 MS>> эти гигабайты разом в память?)

 EM> Почему всего 30 Гб, и почему фотографий, а не видео? :)

 Пусть будет видео)

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.
 * Origin: Сено - великая вещь. (2:5020/828.777)
SEEN-BY: 46/49 452/28 455/19 4500/1 5001/100
5010/352 5019/40 5020/77 181 545
SEEN-BY: 5020/828 848 870 1042 1941 1955 2192
3204 4441 12000 5022/128
SEEN-BY: 5030/1081 5059/37 5097/31 6035/4 6078/80
@PATH: 5020/828 12000 4441