>Существенно улучшить положение может аллокатор, основанный на mmap (mmap--вызов, выделяющий память отдельной областью, пропорционально размеру страницы, 4096 байт) и на соответствующих алгоритмах размещения переменных в памяти.
MMAP(2) Linux Programmer’s Manual NAME mmap, munmap - map or unmap files or devices into memory
При чем сдесь mmap?
>Сначала прочитайте все связанные баги и ссылку внимательно. FF под Win и другие Unix'ы этой проблемы не имеет.
Значит это симбиоз кривого ФФ и кривого алокатора. В любом случае програмеры ФФ видели эту ситуацию с самого начала и не смогли/не захотели под неё подстроится/обойти как это очевидно сделано в других браузерах.
> В любом случае програмеры ФФ видели эту ситуацию с самого начала и не смогли/не захотели под неё подстроится/обойти как это очевидно сделано в других браузерах.
В Opera, например, не сделано (см. выше). Так что далеко не очевидно.
У меня в организации человек _работает_ с XP/Outlook Express/Office 2003 на ... 64MB RAM. Пришлось, правда, половину сервисов отрубить для освобождения памяти. Человек привык больше одного приложения за раз не запускать - swap'ит безбожно.
Значит, повезло не грузить страницы, на которых память хорошо фрагментируется. По опыту, на javascript-intensive страницах у оперы идет основное распухание. Собсно почему и перестал ее в свое время юзать, из-за памяти. Патч для мозиллы в то время уже был.
>У меня в организации человек _работает_ с XP/Outlook Express/Office 2003 на ... 64MB RAM
Я в детстве работал на winxp 64 метрах. Правда на нтфс. Многие функции из аутлука не работали - говорили памяти нету. Загрузка офиса хп с моим дипломом обычно завершалась не корректно. обычная винхп сп1. Про _работает_ не верю.
>По опыту, на javascript-intensive страницах у оперы идет основное распухание.
JavaScript по дефолту там выключенным держу. Кстати, JS у FF2 на P75 - это полные кранты. Вешается вся машина, иногда на многие десятки секунд (как я уже писал, там просто открытие маленькой страницы, даже без JS, занимает 40..50 секунд).