firefox 3 alpha2 release

Нет дружочек. Просто я использую настоящий firefox:

Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

> На вторых и третьих пнях, да и вообще на любой машине они работают мягко говоря быстрее.

На любой: здесь уже сравнивали FF и Opera > 7 на P150/48M/S3V. Результаты неожиданные.

Сцуко, от Дреппера сотоварищи не ожидал такой зосады ! Чайнеги !

По пункту mallopt() придется признать себя ослом. Я был уверен, что он работает как BSDшный.

Однако:

1) внутри ФФ есть еще куча кода на C++, a new() не факт, что вызывает malloc(). Я внутрь g++/libstdc++ не смотрел, но по крайней мере ltrace вызовов malloc() не показывает, а вот strace показывает, что вызывается sbrk().

2) от ФФ толстеет еще и X-сервер. Есть предположение, что ФФ заставляет последний (с помощью функций а-ля XInternAtom) создавать кучу ресурсов, которые потом не освобождаются (либо XFree вызывается, но в силу указанной Вами проблемы с malloc()ом X'ы тоже не могут "похудеть"). Более того, при вызове XCloseDisplay() атомы, созданные в процессе работы с закрытым соединением, не освобождаются. Поэтому, если эта гипотеза верна, то сколько ФФ ни перезапускай, а X'ы рано или позно сами всю память сьедят.

Однако попробуем попускать Ваш аллокатор. Посмотрим, насколько полегчает.

К последнему сообщению попраффка: вместо

strace показывает, что вызывается sbrk()

следует читать:

strace показывает, что вызывается brk()

Потому как sbrk() не системный вызов и strace его показывать не может.

> внутри ФФ есть еще куча кода на C++, a new() не факт, что вызывает malloc().

Не нашел других куч, кроме arena glibc malloc. При сборке без --enable-xpcom-doug-lea (не помню точно опцию), вероятно, в glibc malloc упирается везде.

Для некоторых классов, где new идут пачками подряд, а потом delete не подряд, возможно, может помочь переопределение new с заточенным аллокатором со своей кучей/кучами. Но в mozilla этого нет по умолчани/

> strace показывает, что вызывается sbrk().

brk()

> 2) от ФФ толстеет еще и X-сервер.

LD_PRELOAD=/path/to/libOpenBSD-malloc.so startx помогает и им тоже.

У меня так X-сервер всю дорогу работает. На машине 48M RAM. Можно долго держать открытым mozilla-1.7.13, ff-1.* (slackware 10.2)

A на 64M RAM с LD_PRELOAD=... startx юзабелен KDE 3.4 (slackware 10.2)

NB: overload *alloc/*free не вызывает сбоев не на всех дистрибутивах. Причины не выяснялись. Глюки были на ALT Sisyphus > ALT 3.0, кто-то здесь говорил про сбои и на других. Без глюков сам проверял: Slackware 10.2, ALT 2.4, 3.0, SLC3, SLC4.

> Slackware 10.2, ALT 2.4, 3.0, SLC3, SLC4.

ЗЫ в более новых glibc, libstdc++ что-то поломано?

Если бы это была одна полоска:

http://slil.ru/23900811

> Однако попробуем попускать Ваш аллокатор.

Автор порта на линукс че-то здесь не появляется.

>Если бы это была одна полоска:...

Интересно, почему один и тот же фф по-разному криво показывает эту несчастную рожу 8)

> А что насчет скорости?

Скорость стала ещё выше, разумеется. Я этой второй альфой пользуюсь уже несколько месяцев, замечаний не имею.

>Что-то вы делаете не так ;) Ни разу такого не видел, FF живет _неделями_ на машине c 128M

Вполне может быть, что дело в amd64. (128Мб... Хе-хе... У меня только Иксы до 170Мб жрут)

> ахахах про то что хоткеи не пашут - ни слова, а это самая заметная проблема для пользователей

А какие с ними проблемы? Вроде ж пашут :o\

> Вполне может быть, что дело в amd64.

Странно сие. amd64, дистрибутив SLC4, ff 1.5.0.9 ест в среднем меньше 100M.

Никогда не держал его там неделями, эта машина только для кросс-проверок ia32 <-> amd64. Можно и подержать, конечно.

> а в том, что FF 2.0.0.2, оставленный на выходные, может сожрать за ночь 650Мб оперативки при семи открытых табах без флеша и жрать при этом 60..70% CPU

Где вы такие firefox`ы берете? У меня оно неделями пашет без перезагрузок и ничего не отжирает. Если без флеша. Со флешем эти самые 60-70% CPU, это да. Благо на youtube я обычно хожу mplayer`ом, а рекламные флешки AdBlock не пускает. Ещё вроде особо зложные JavaScrip`ы могут процессор травить слегка, но такое встречается слишком редко, чтобы убедиться (реже, чем броузер обновляется на следующую версию, в силу чего приходится его перезапускать таки).

>Интересно, почему один и тот же фф по-разному криво показывает эту несчастную рожу 8)

Может у кого-то отключены картинки а у кого-то включены? Я как-то замечал, что это влияет (на какой-то Опере).

А ты как думал. #ifdef знаешь что такое?

OPERA FOREVER!!!! OPERA FOREVER!!!! Что не говори - фарева!

Красноглазые подтянулись.

>Если бы это была одна полоска

Если у вас две полоски - надо срочно собирать деньги на роддом...

Ну вот обьясните мне, почему Опера не открывает исходники? Денет они с нее не получаютю Опере Мини тоже пофигу, так как она ничего общего с ПК, кроме названия не имеет... Чего??? Или они надеются подсадить всех на Оперу, а потом обратно платность ввести..? Х...я!

>Так летает, что не заметил, как 2 раза запостил?

Это ЛОР своими глюками задолбал! Пишу сообщение, ввожу код проверки (вроде правильно), нажимаю post, а он мне отвечает "Ошибка проверки кода". Я снова ввожу код, вроде проходит... А потом обнаруживаю, что запостил 2 раза :(((

>раз уж зашел разговор про файрфокс, решил спросить у опероводов - почему opera не использует linguist??? ИМХО для разработчика ОЧЕНЬ удобная фича QT...

Эээ, а зачем??? Помоему, проще соответствующий lng-файл написать.

>Пишу сообщение, ввожу код проверки (вроде правильно), нажимаю post, а он мне отвечает "Ошибка проверки кода".

Может ты бот?

Периодически случается. Помогает чистка куков.

Это... Как отключить автоматическое открытие диалога выбора файла при клике на форму , где должен указываться путь файла?? Ну вы меня поняли :)

> TO:webmaster@thatuglyhost.com CC:root@thatuglyhost.com

> Думаю, что эти адреса уже давно никто не проверяет. Представь, сколько на них спама сыплется.

А Байес на что?

>>если в нем оставить страницу открытой с автоматической перезагрузкой этой страницы, он через 3 дня у меня 500Mb рамы отьедает.

>http://mr.himki.net/index-alloc.html

А почему в других программах такого нет, а в FF есть? Не то, что наезжаю, просто любопытно, в самом деле.

>>http://mr.himki.net/index-alloc.html

>А почему в других программах такого нет, а в FF есть?

Есть: opera, konqueror, etc. etc. Бибилиотека по той ссылке им тоже помогает от последствий фрагментации.

>Есть: opera, konqueror, etc. etc. Бибилиотека по той ссылке им тоже помогает от последствий фрагментации.

А что же тогда все орут только про FF? Непорядок!!

Честное пионерское. Cairo используется на всех платформах, в этом собственно и был смысл переписывания всего на cairo. Кода становится меньше, а еще бесплатно получаются backend-ы от cairo, поддерживающие аппаратное ускорение и всякая мутотень типа "сохранить в PDF".

А то как рисуются виджеты - это совсем другой вопрос. На всех платформах происходит эмуляция родного look and feel'а системы, обычно через системные вызовы (например gtk или винапи), но реальных нативных widget'ов не создается.

О боже. Если бы вы удосужились открыть собственно release notes, вы бы заметили, что ни в какой Mozilla не лодке (точнее, положение не изменилось с Fx3).

Просто автор новости не смог выучить на достойном уровне и перевел фразу "The non-standard JavaScript _Script_ object is no longer supported." как "Нестандартные JavaScript-объекты тоже вычищены. Веб-мастера, не следующие W3C -- берегитесь!".

Для тех, кто в танке за Берлинской стеной, перевожу: "Нестандартный объект JavaScript под названием 'Script' больше не поддерживается". Объясняю, Script - наследие Netscape, не поддерживающееся ни в IE, ни в опере.

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

По-моему, все более-менее разумные люди знают, что во всех крупных программах память течет. Так же, как и в Fx. Говорю вам, как человек, близко знакомый с кодом Fx.

Вопрос в объемах. Объемы действительно преувеличивают, но и крупные утечки возможны. Если человек, например, поставит недостаточно качественное расширение или изменит неподдерживаемую настройку.