LINUX.ORG.RU

Сравнение потребления памяти популярными браузерами

 , , , , , , , ,


0

0

Энтузиастом был проведен эксперимент по сравнению потребления памяти современными популярными браузерами. Замеры производились на первых 120 сайтах из Alexa TOP-1000000, измерение потребляемой оперативной памяти производилось при открытии каждой новой вкладки, «забегов» производилось три: до 9, 29 и 120 вкладок.

Кратко о результатах: больше всех памяти съел легковесный браузер uzbl, за ним быстрый Chromium, за ними Rekonq и Opera, далее с большим отрывом leechcraft, midori, firefox. Самым лёгким оказался браузер arora.

График потребления памяти до 120 вкладок.

>>> Подробности и графики

★★

Проверено: JB ()

Чихать на память. У меня постоянно не больше 1 из 4 ГБ занято. Готов отдать FF гектар памяти чтобы он работал так же как и Chromium или быстрее. Да, на Gentoo FF работает как Chromium на Ubuntu, но тут дело в системе и Chromium на Gentoo вообще срабатывает моментально. FF остатеся тормозом. Рад что слез с него.

vertexua ★☆☆☆☆ ()
Ответ на: комментарий от tailgunner

> Акцент на «значительные»

вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

anonymous ()
Ответ на: комментарий от anonymous

>> То есть ты считаешь, что development snapshot должен быть так же безглючен, как финальная версия?

> Я считаю если не готово - не предлагай, не будем и судить.

Повторю: «release early, release often» - стандартная практика FOSS.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

> Ни разу не очевидно. Откуда в процессной модели значительно большие требования по памяти?

«Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.» (http://en.wikipedia.org/wiki/Thread_(computer_science))

Хотя насчёт значительных может и погорячился.

P.S. Вот здесь говорится о том, что RSS вообще не показатель, ибо каждый раз считает разделяемые библиотеки.

Lothlorien ★★★ ()
Ответ на: комментарий от anonymous

> вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

Калькулятор нужен. А то мой может насчитать только 480К чистого оверхэда - на стеки ядра.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

boo32 ()
Ответ на: комментарий от anonymous

> Но в любом случае за ошибки в плагинах ответственны не браузеры.


так же можно сказать, что за хреновый жаваскрипт браузер не несет ответственности

m ()
Ответ на: комментарий от Lothlorien

> «Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.»

Дело в том, что процессам и не нужно разделять per-thread ресурсы, если каждая нить обслуживает свою вкладку - вкладки независимы.

tailgunner ★★★★★ ()
Ответ на: комментарий от m

да, не несёт, и потому джабаскрипт спроектирован безопасным, чтобы ошибки программ на js не могли вылезти за пределы интерпретатора.

boo32 ()
Ответ на: комментарий от boo32

> хромиум сырой, не смотря ни на что. понимаешь?

А ты понимаешь, что назвал разумную архитектуру костылями?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

я пояснил критерии её неразумности. знаешь байку про хакера и солонки в общественной столовой?

boo32 ()
Ответ на: комментарий от tailgunner

>>> То есть ты считаешь, что development snapshot должен быть так же безглючен, как финальная версия?

>> Я считаю если не готово - не предлагай, не будем и судить.


>Повторю: «release early, release often» - стандартная практика FOSS.


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

anonymous ()
Ответ на: комментарий от tailgunner

> > «Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.»

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

Ну да, а общий набор переменных состояния браузера (те же закладки, наличие информации в кэше браузера, наконец X-овый контекст вывода) тоже не нужен?

Lothlorien ★★★ ()
Ответ на: комментарий от m

>так же можно сказать, что за хреновый жаваскрипт браузер не несет ответственности

А что, за него несут ответственность «инженеры мозиллы», которые и наделали в нем ошибок?

anonymous ()
Ответ на: комментарий от boo32

Да, да, конечно. Ведь на javascript можно написать только безопасный код!

m ()
Ответ на: комментарий от anonymous

> мы начинаем его тестировать и имеем право судить о качестве.

Суди, не вопрос. Только слишком далеко идущих выводов не делай.

tailgunner ★★★★★ ()
Ответ на: комментарий от m

> Да, да, конечно. Ведь на javascript можно написать только безопасный код!

«да, да, конечно. ведь в отдельном процессе можно написать только безопасный код!»

boo32 ()
Ответ на: комментарий от Lothlorien

> Ну да, а общий набор переменных состояния браузера (те же закладки, наличие информации в кэше браузера, наконец X-овый контекст вывода) тоже не нужен?

Это же копейки.

tailgunner ★★★★★ ()

>больше всех памяти съел легковесный браузер uzbl

Led Bicycle.

Что-то полюбили в последнее время слово «убогий» заменять словом «легковесный». Это нехорошо.

thesis ★★★★★ ()
Ответ на: комментарий от tailgunner

>> вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

> Калькулятор нужен. А то мой может насчитать только 480К чистого оверхэда - на стеки ядра.

Хотя что это я... в Линуксе же модель 1:1, так что для каждой нити всё равно создается стек ядра... значит, явные накладные расходы - только структуры менеджера памяти. Не знаю, правда, как их подсчитать.

tailgunner ★★★★★ ()

Цвета на графики не очень голубой и синий у меня очень-очень похоже выглядят. Да и тест немного неумный... лучше бы они сравнили отзывчивость (;

hired777 ()
Ответ на: комментарий от anonymous

>Ты сам это видел или прочитал самопальный советский пеар? Если жигуль и разовьёт 200 км/ч в городе (в чём я не уверен - у роторных двигателей много проблем), то финишируют передняя и задняя части авто по отдельности, т.к. жёсткости кузова у жигулей нема.

Видел конечно но не в городе - никто не развалился, а вот иномарины только дым нюхали, бэхи в том числе да в общем все :) Естественно по управляемости им не сравниться и с поворотами они так не справляются как иномарки.

bengan ()
Ответ на: комментарий от thesis

>полюбили в последнее время слово «убогий» заменять словом «легковесный». Это нехорошо.

Зато позитивно.

massimus ★★ ()
Ответ на: комментарий от bengan

> Видел конечно но не в городе - никто не развалился, а вот иномарины только дым нюхали, бэхи в том числе да в общем все :) Естественно по управляемости им не сравниться и с поворотами они так не справляются как иномарки.

где можно поглядеть на сие чудо и их заезды? )

anonymous ()

На графике midori график дальше 54 вкладок не пошел потому что хана ему настала, или потому что память больше 600мб и он опятьтаки загнулся?

px ★★★ ()
Ответ на: комментарий от anonymous

>где можно поглядеть на сие чудо и их заезды? )

Я видел у рейсера один раз, не очень они популярны из-за малого ресурса двигателя, причем у него как раз был списаный гэбэшный вариант. Тут посмотри:

http://www.ladaonline.ru/catalog/index.php?SECTION_ID=355&SHOWALL_1=1

bengan ()
Ответ на: комментарий от hired777

А как ее сравнивать, не научите?

anonymous ()
Ответ на: комментарий от MuZHiK-2

> Мы сейчас говорим о том случае, когда ошибка произошла. Вне зависимости от того, кто в этом виноват. В данном случае треды поведут себя куда опаснее.

А почему опаснее? Посмотрим на это с другой стороны. Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код. А код, выполняемый в одном процессе, легко получит доступ к данным остальных процессов этого юзера. То есть безопасности данных это не способствует.

Смотрим дальше. Когда каждая вкладка - это отдельный процесс, то организовать взаимодействие между ними сложнее. А взаимодействовать им придется - у них много общих ресурсов, начиная от клавиатуры, мыши, кеша, аудио и плагинов, и заканчивая отдельными элементами страницы, ведь javascript одной вкладки может иногда управлять другой.

В потоковой реализации это было бы обычное IPC, но для разных процессов все намного сложнее. А чем сложнее код - тем больше в нем ошибок. А чем больше ошибок - тем хуже безопасность. С этой точки зрения хром - наименее безопасный браузер.

И на практике, когда хром падает, он падает весь, а не вкладками. Так где же на практике вся эта распиаренная безопасность?

anonymous ()
Ответ на: комментарий от px

Хана ему настала, но вроде как не от количества занятой памяти. Почитай соответствующий кусок текста.

anonymous ()
Ответ на: комментарий от anonymous

Несмотря на то, что твой текст полон технических неточностей, ты в общем прав.

anonymous ()
Ответ на: комментарий от tailgunner

> Это же копейки.

Как сейчас пишут, вовсе могут быть и не копейки ;)

BTW, судя по исходникам хромиума, часть библиотек он таки линкует статически, что ещё отжирает память. В thread-модели такого не было бы (впрочем, статическая линковка библиотек — это костыль).

Lothlorien ★★★ ()

Класс!

Мой любимый браузер оказался лучшим. :)

Jayrome ★★★★★ ()
Ответ на: комментарий от Lothlorien

> Как сейчас пишут, вовсе могут быть и не копейки ;)

Откуда там не копейки? Здравый смысл подсказывает, что память жрут: 1) DOM tree (которое по определению отдельное на каждую вкладку); 2) интерпретатор JavaScript, который тоже должен быть отдельный для каждой вкладки. Если вынести это в отдельный процесс, памяти они больше жрать не станут.

> судя по исходникам хромиума, часть библиотек он таки линкует статически, что ещё отжирает память.

Для многопроцессной модели это неважно.

tailgunner ★★★★★ ()

>Chromium (chromium-bin-5.0.376.0_p44230) (без аддонов)
>Firefox 3.6.3 (без аддонов)

олошеньки лоло. кто ж фуррифоксом то без обвесок пользуется? адблок поди памяти не жрет совсем?

>Opera 10.10-r1 (более свежие версии неработоспособны вообще) (без всяких довесков)

два вопроса: 1. в каком месте они не работоспособны? 2. какие в опере могут быть довески?
и тем не менее, несмотря на всю сомнительность тестов, Опера таки лучше хрома. браво.

devnullopers ()
Ответ на: комментарий от anonymous

> Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код...

после этой х-ни остальное можно не читать XD

anonymous ()
Ответ на: комментарий от anonymous

>> Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код...

> после этой х-ни остальное можно не читать XD

Разжую для тупых программистов и обычных непрограммистов. Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти. Очевидно, разработчики не задумывали это при разработке кода, и раз это произошло, то выполнился совсем не тот, код, который должен был выполниться.

Например, при переполнении стека из-за парсинга какого-то левого яваскрипта после возврата из функции управление было передано на совершенно левую область памяти, и браузер упал. Соответственно, изменив этот «левый» яваскрипт, можно добиться того, что процесс будет передавать управление на заранее подготовленную область памяти с кодом.

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

Дальше, в зависимости от реализации в разных областях памяти могут храниться указатели на разные переменные. Повреждение таких указателей тоже может вызывать падение браузера. Но если один из них повредить хитрым образом, то вместо крэша это даст доступ к области памяти, которая не должна была быть доступна. Код таким образом не выполнить, но доступ к «закрытым» данным получить можно.

Ну что, теперь уже не так смешно?

anonymous ()
Ответ на: комментарий от anonymous

>...Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти...

Прям как в анекдоте про корову :)

- Коробочка квадратная.
- Значит, в ней что-то круглое.
- Раз круглое, значит оранжевое.
- Значит, апельсин.

WFrag ★★★★ ()
Ответ на: комментарий от WFrag

т.е., ты не в курсе, как анализировать дамп упавшего процесса и написать эксплоит?

boo32 ()
Ответ на: комментарий от boo32

> не смешно, потому что ничего не понял?

Нельзя же так подставляться под обвинение в дислексии...

m> все еще смешно

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

boo32 ()

Ахахаха!!!! Ушат холодной воды на хромиум-фанов.

Фаерфойс лучший!

anonymous ()
Ответ на: комментарий от anonymous

> Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти. Очевидно, разработчики не задумывали это при разработке кода, и раз это произошло, то выполнился совсем не тот, код, который должен был выполниться.

ха-ха, клоунада в действии )) в том-то и дело, что обращаясь к недоступной странице памяти, процесс вызывает исключение segfault и аварийно завершается средствами самой ОС. В firefox'е процесс един для всех вкладок, поэтому, имея общую память, зловредный код из одной вкладки, может получить доступ и к другим, что логично, а так же положить и весь браузер (процесс един для всех вкладок, интерпретатора javascript'а, помним об этом, да?). В chrom'е на каждую вкладку выделяется свой процесс, поэтому уронив одну из вкладок, вызвав ошибку доступа к памяти, вкладка не потянет за собой весь браузер. И о чем ты спорил? ))

anonymous ()
Ответ на: комментарий от devnullopers

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

anonymous ()
Ответ на: комментарий от anonymous

> в том-то и дело, что обращаясь к недоступной странице памяти

почему недоступная? она доступна, просто содержит мусор из переполненного буфера.

> В firefox'е процесс един для всех вкладок, поэтому, имея общую память, зловредный код из одной вкладки, может получить доступ и к другим, что логично

но в фаерфоксе твоя реальность перестаёт работать, и там уже страница памяти доступна?

> В chrom'е на каждую вкладку выделяется свой процесс, поэтому уронив одну из вкладок, вызвав ошибку доступа к памяти, вкладка не потянет за собой весь браузер.

потянет, ибо процессы-таки делят некоторые структуры в памяти, и при опаньке в одной вкладке в аут уходит весь браузер.

ты кроме бейсика в программировании что-нибудь понимаешь?

boo32 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.