Nп/п : 21 из 100
 От   : Maxim Sokolsky                      2:5020/828.777    21 апр 25 21:02:34
 К    : Eugene Muzychenko                                     21 апр 25 21:09:02
 Тема : Re: Файл подкачки и фидо-софт
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:5020/828.777 68067a3c
@REPLY: 2:5000/14 6805ee4b
@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>> К уровню программистов это отношения ни имеет.

 EM> К уровню программистов имеет отношение экстенсивность использования
 EM> _памяти_, а не _адресного_пространства_.

 Hу м.б., тогда мы о разном.

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

 EM> А если физической памяти хватает для повседневной работы, то можно, но
 EM> не нужно. Как и на HDD.

Это должно быть обосновано - для какой цели отключать файл подкачки.
 И - а если. Администратор системы должен понимать, что если он
отключит файл подкачки и по какой-то неизвестной для него причине свободное
ОЗУ внезапно закончится, то некоторые процессы вылетят с ошибкой, что
приведет к _внезапной_ потере пользовательских данных.
 Файл подкачки дает администратору системы возможность исправить
ситуацию. В случае нехватки ОЗУ, система начинает использовать файл подкачки
активнее и начинает работать медленнее, поэтому данные сразу не теряются. По
крайней мере до тех пор, пока не исчерпается память файла подкачки.
Администратору в это время приходят смс-ки системы мониторинга, начинают звонить
рассерженные пользователи и ругаться, что система "тормозит". Т.е. у него остается
время отреагировать и попытаться исправить ситуацию с нехваткой ОЗУ.

 MS>> Тоссер же старый? Старый. 32-разрядный. Hу вот Чеславу и глюки.

 EM> Каким образом свойства "старый" и "32-разрядный" могут увеличивать
 EM> вероятность глюков?

  Мало ли что в старом коде может быть, что не совместимо с WoW64.
Она преобразует 32-битные данные в 64-битные, и у нее есть много
ограничений.

>---=== Куть он "Windows Clipboard" ===---
Ядро не может выполнять 32-битный код.
Поддержка 16-битного кода была удалена.
То же самое относится к подсистемам OS/2 и Posix.
Смешанные 32-битные/64-битные процессы не допускаются.
64-битные приложения могут загружать только 64-битные DLL и OCX.
32-битные приложения могут загружать только 32-битные DLL и OCX.
 Скрипты и плагины также не могут запускать одновременно 32- и
64-битные процессы.
>---=== Куть офф "Windows Clipboard" ===---

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

 EM> С чего бы вдруг? Оно лишь _не_менее_эффективно_, да и то в среднем.

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

С уважением - 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



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх