Один из разработчиков Mozilla сообщил о возобновлении работ, связанных с проектом Electrolysis, в рамках которого запланирован перевод Firefox на многопроцессную архитектуру, при которой пользовательский интерфейс и обработка контента будут обрабатываться разными процессами. Кроме того, рассматривается возможность использования многопроцессной модели для обеспечения полной изоляции отдельных вкладок, виджетов, групп вкладок и страниц одного домена.

Часть наработок проекта уже интегрирована в Firefox 4 и используется для выполнения плагинов в отдельных процессах. Кроме того, в Mobile Firefox 4.0 для платформы Android уже задействован механизм обработки вкладок разными процессами. Отмечается, что процесс перехода на многопроцессорную модель достаточно сложен и длителен, новая архитектура будет внедряться постепенно. Конкретные сроки не указаны, но с учетом 16-недельного цикла подготовки релизов, новые наработки можно будет увидеть не раньше, чем в версии Firefox 8. По заявлению разработчиков Mozilla, каждый новый релиз Firefox будет быстрее и стабильнее, интерфейс станет более отзывчивым.

В качестве основных факторов, рассматриваемых при планировании перехода к многопроцессной архитектуре, называются:

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

    В конечном итоге наблюдается увеличение фрагментации хранилища и время поиска сборщиком мусора неиспользуемых объектов. Во время работы сборщика мусора основной цикл обработки событий приостанавливается и наблюдается замедление реакции на действия пользователя, вплоть до секундных подвисаний. В Firefox 4 предпринято несколько попыток улучшения интерактивности, например, для разных классов объектов в хранилище задействованы отдельные методы сборки мусора, а также уменьшен интервал активации сборщика мусора. Тем не менее, все проблемы не решены, а лишь найдены временные обходные пути для определенных ситуаций. Например, проблемы с интерактивностью продолжают наблюдаться при очистке памяти после работы больших web-приложений.
    Оптимизация для многоядерных процессоров. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки контента может быть задействовано только одно ядро CPU.

    Самым простым выходом из сложившейся ситуации является реализация возможности запуска нескольких DOM-обработчиков в виде отдельных процессов, которые смогут работать параллельно не мешая друг другу. Одновременно развивается альтернативный проект, поддержка многопоточной обработки DOM-дерева в котором реализована благодаря переработке кода на языке Rust, напоминающем C++, но поддерживающем автоматическое управление памятью и выполнение задач в виде легковесных сопрограмм.
    Предсказуемое потребление памяти. Значительными проблемами в Firefox остаются: большая фрагментация памяти, трудности с перераспределением памяти, невозможность отдачи уже полученной от ОС памяти и утечки памяти. Данные проблемы не являются специфичными для Firefox и неизбежно возникают у любого длительно работающего процесса, интенсивно манипулирующего блоками памяти. В случае выделения памяти разного размера со временем растет фрагментация и остается все больше небольших "дыр" от ранее освобожденных объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока.

    В случае обработки web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобиться в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.
    Защита от сбоев. Очевидно, что в случае выхода за пределы допустимой границы буфера или при возникновении другой внештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме. В частности, уже реализованная технологий выноса плагинов в отдельные процессы позволила заметно увеличить надежность работы, например, крах Flash-плагина больше не отражается на работе браузера.
    Повышение безопасности. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе. Практика браузера Chrome показывает, что за всю историю существования проекта было обнаружено лишь несколько уязвимостей, позволяющих обойти многоуровневую защиту.

http://www.opennet.ru/opennews/art.shtml?num=31227

Лучше бы более активно занялись ПРОБЛЕМОЙ утечек памяти.

Давно пора.

Отличная новость, что работы над Electrolysis'ом возобновлены. Спасибо!

Конечно, это уже давно известно, но..
У меня почему-то иногда возникает ситуация, когда убийство plugin-container'а выводит подвисший браузер из полного ступора.

не течёт. Проверено.

plugin-container можно отключить в about:config, и это иногда даже исправляет проблемы с торможением видео, но не исключено, что тогда придётся завершать не его, а сам firefox.

19-07-2011 22:32:56

Подтверждаю. Так что проблема скоро может исчезнуть.

Йцукен
Дык, в том то и дело, что контейнер должен разделять плагины и браузер. Но, у меня это не всегда работает, то есть, создается такое ощущение, что никакого разделения нет.
Но, справедливости ради, бывает такое не часто.

У меня 8-ка, которую сегодня собрал, работает уже часов 5. Вкладок открыто 12 (активных) и ещё около 30-ти открыты, но не обновлены (лежат себе по группам в панораме). Три десятка аддонов (включённых и ещё столько же не включённых). Память держится в пределах 400-430 MiB И это при том, что фокс 64-битный, а параметр browser.sessionhistory.max_total_viewers выставлен 25.  Ничего не течёт.
:::: Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110719 Firefox/8.0a1

=Agasfer=
ща найдется тот кто скажет что это из за линукса

Тестирование браузеров на скорость Ближе к концу поста. Показан огромный размер утечек в различных версиях windows-ночнушек.

Скажите, есть где-нить на сайте Мозилы страница, имеющая постоянно обновляемые, даты выхода версий в релиз? То есть сейчас она будет показывать 6,7,8 когда будут релизами, после выхода 6, чтобы 9 добавилась и тд

mcfly
Есть что-то такое.

Бгг. До сих пор помню как мне на экзамене поставили четвёрку за то, что я написал код, работающий без утечек памяти, но НЕ ПО СТАНДАРТУ ЯЗЫКА "ПАСКАЛЬ"   С той поры я принципиально пишу код с утечками памяти. Если утечек нет - добавляю по таймеру

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

Как формулируется этот "принцип"?

17-08-2011 01:16:29

Вопрос.
Как это перевести на нормальный язык для обычного человека? Значит ли это, что после этого "перевода" браузер не будет работать на однопроцессорной машине?

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

nosync
Речь о многопроцессной, а не о многопроцессорной архитектуре

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

nosync
Сам браузер - 1 процесс;
Плагины в плагин-контейнере;
Расширения в плагин контейнере, или в отдельно запущеном специально для этого расширения плагин-контейнере, если это прописано в коде расширения;
Содержимое вкладок в отдельном процессе.

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

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

Ждем хотя бы проблеска понимания... Но видимо не в этом году

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

Что серьёзно?  about:support  > граф«Многопроцессные окна» что написано?

У меня написано 1/1 (Включены пользователем)
Я вручную включила 3 процесса, в версии 49.x это были три plugin-container, в версии 50.x - дополнительные три процесса firefox.exe (всего 4). Windows XP, 3Gb памяти. Работает стабильно, расход памяти увеличился на 40% (примерно), но для меня это приемлемо. Довольна этой функцией, небольшой выигрыш в скорости есть, да и в надёжности тоже (если один из дочерних процессов "подвис", его можно завершить через панель задач, при этом продолжает работать).

Лучше оставили все как есть, как старую Оперу. Чем больше возможностей для мульти процессности, тем больший тормоз получаем. Посмотрел бетку 51, ничего хорошего. По производительности хужее 50. Лучше бы движок Servo допиливали. Ушел пока в ожидании перемен на китайский хромоклон. После него лиса воспринимается как тормоз. Раньше пользовался из-за того, что расширения есть такие каких нет у хромоклонов, так их через некоторое время поубивают, и на фиг нужна такая лиса?

Что? Что серьёзно?  В about:support 1/1 окон многопроцессных. В смысле одно многопроцессное окно и два процесса лисы в диспетчере, больше включать пока не хочу, жрется очень память.
А по поводу плагинов вот http://arewee10syet.com/

Хмм. Заметил интересную вещь. с e10s под вин10 в плане памяти и производительности гораздо лучше себя ведет чем с e10s под вин7. Под вин10 расход памяти находится на одном уровне то есть не разжирается со временем как єто есть в вин7. Так же и с производительностью. Если в вин7 после определенного времени активного серфинга начинает медленнее работать, то под вин10 єтого нет.

ps
вин10х64, ноут, i3, х64 + e10s
вин7х64, пк, i5, х64 + e10s

pps и єто при том что на в вин10 установлены якобы несовместимые дополнения с e10s, никаких крахов, багов, зависаний нет.

Ось поменялась, суть (движок Gecko) осталась. Не смешите своим выводом.

Похоже у вас ХР установлена. Win10 на порядок умнее и способнее своих предшественниц. Обеспечивает наилучшие режимы работы для программ и устройств. При чём делает это автоматически без вмешательств пользователя. Взять хотя бы драйвера для устройств, устанавливаются автоматически. Не то, что на семёрке - замучаешься эти драйвера искать. Можно, конечно, сохранить драйвера для переустановки ОС, или Гигабайтные сборки драйверпаков под рукой иметь. Но это всё лишние заморочки.

То что увидел у себя описал. Могу ошибаться конечно. Но под вин10 даже на чуть более слабом пк, лисица лучше работает.

Зарегистрировался специально чтобы написать.... новая лиса -это супер, как только включил многопроцессорность принудительно(некоторые дополнения не поддерживаются) все тормоза прошли, теперь работает отлично, как старая добрая 12 опера.

ps.
комп MB air 2015/i7/8GB
постоянно работаю с 30-50 вкладками

andr2k
Как включить эту многопроцессорность? На версиях 32 бит работает?

28-01-2017 23:13:41
Включил, действительно, очень шустро стало работать. Но минимум одно дополнение косячит. Потестирую пока для себя.

На XP, двухъядерный проц - так же всё быстро работает, естественно с блокировщиком рекламы. Кстати, на работе есть комп с XP, селерон 2,4ггц 1 гиг оперативы 2003 или 2004 года, на котором старая опера и новая лиса. Так старая опера уже много где не справляется с новым вебом и тормозит. На лисе всё летает и никакого дискомфорта старого железа не ощущается.

andr2k
kanker

многопроцессность, от - много процессов

kanker
В about:config
browser.tabs.remote.autostart - true
browser.tabs.remote.autostart2 - true
browser.tabs.remote.force-enable -true
но некоторые дополнения могут глючить из-за несовместимости с многопроцессным режимом, вот список https://arewee10syet.com

grey_rat
да под ХР отлично работает даже на ноуте 2005 года

Доброй ночи, господа. Такой вопрос, как я понял в 51-версии добавили многозадачность. Теперь в диспетчере задач висит 2 процесса от firefox.exe /

Для чего это? И можно ли как-то от этого избавиться?

Это теперь как в google chrome будет по 10 копий висеть?

UPD/ Беру слова обратно. Протестировал с многозадачностью и без, "С" работает вроде быстрее, но как по мне, памяти стал кушать чуть побольше. Видимо из-за того что теперь два процессора это  вкладки и интерфейс отдельно.

StarWars
Без аддонов быстрее, с аддонами медленнее, ибо они под эту многопроцессность не писались в основном, а работают через какую-то программную прокладку, замедляющую скорость работы браузера. Как их перепишут под e10s, будет быстрее и с ними.

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

29-01-2017 15:26:12

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

например, вот уже автор прекращает разработку из-за перехода на WebExtentions   http://fasezero.com/

12
Вон тут в соседней теме pag77, разраб аддонов пишет, что некоторые из них невозможно переписать под WebExtensions, а некоторые вполне, и некоторые с ограничением функционала. Ему в мозилле сказали, что в будет расширенный WebExtensions, функциональнее, чем в Хроме.