Разработчики Mozilla опубликовали (https://blog.mozilla.org/futurereleases/2016/12/21/update-on.../) обновлённый план перевода Firefox на многопроцессную архитектуру с разделением на разные процессы обработчиков контента и интерфейса (все обработчики контента выполняются отдельно от интерфейса, но пока (https://www.opennet.ru/opennews/art.shtml?num=45480) в одном процессе друг с другом). Сообщается, что предварительное внедрение многопроцессного режима для отдельных категорий пользователей прошло успешно и если не возникнет непредвиденных проблем, включение многопроцессного режима для всех пользователей ожидается в выпуске Firefox 51, запланированном на 24 января. Исключение будет сделано только для конфигураций, в которых встречаются дополнения, помеченные как явно несовместимые с многопроцессной архитектурой.Напомним, что в Firefox 48 (https://www.opennet.ru/opennews/art.shtml?num=44897) многопроцессный режим был предложен примерно 1% пользователей (затем расширен до 50%), не использующих дополнения и средства для людей с ограниченными возможностями. В Firefox 49 (https://www.opennet.ru/opennews/art.shtml?num=45180) тестирование было расширено на пользователей ограниченного списка дополнений, проверенных на предмет совместимости с многопроцессным режимом. В Firefox 50 (https://www.opennet.ru/opennews/art.shtml?num=45496) многопроцессный режим был включен для систем со всеми проверенными дополнениями. В Firefox 51 вместо белого списка разрешённых дополнений, будет применён чёрный список явно не совместимых дополнений.
Многопроцессный режим позволяет увеличить безопасность, повысить отзывчивость интерфейса, минимизировать подвисания во время сборки мусора и заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения неблокирующих друг друга операций. По тестам Mozilla на многоядерных системах наблюдается увеличение отзывчивости интерфейса на 400% и ускорение загрузки страниц на 700%. Параллельно разработчики развивают две инициативы по расширению многопроцессного режима:
- В ночных сборках проходит тестирование возможность обработки контента в разных процессах. В отличие от уже применяемого разделения на два процесса - один для обработки содержимого вкладок и один для формирования интерфейса, новая возможность позволяет запустить более одного процесса для обработки контента (число запускаемых процессов для обработки контента задаётся через переменную dom.ipc.processCount в about:config). Подобный подход позволяет обеспечить дополнительную изоляцию обработчиков, повысить надёжность (крах одной вкладки не приведёт к закрытию всех остальных вкладок), повысить эффективность использования ресурсов многоядерных процессоров (разнесение нагрузки на все ядра), уменьшить фрагментацию памяти при длительной работе браузера.
- Реализация sandbox-изоляции (https://wiki.mozilla.org/Security/Sandbox), ограничивающей доступ дочерних процессов Firefox к системным вызовам, файловой системе и сторонним процессам. В настоящее время sandbox-изоляция уже применяется на платформе Windows и в одном из следующих релизов будет предложена для macOS и Linux. Для изоляции в Linux применяется ограничение доступа к системным вызовам (https://wiki.mozilla.org/Security/Sandbox#Permissions_burndown) при помощи (https://wiki.mozilla.org/Security/Sandbox/Seccomp) Seccomp-bpf (https://www.opennet.ru/opennews/art.shtml?num=33654), также для изоляции используются (https://code.google.com/p/chromium/wiki/LinuxSandboxing) PID namespace и chroot в пустую директорию. В Windows применяются разработанные Google библиотеки sandboxbroker и sandboxtarget, используемые в Chromium и Chrome.
URL: https://blog.mozilla.org/futurereleases/2016/12/21/update-on.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=45746
> В Windows применяются разработанные Google библиотеки sandboxbroker и sandboxtarget, используемые в Chromium и ChromeЗабавно. Все больше и больше гугловского кода внедряется в фурифокс.
Какого такого кода ? В linux подобное есть изкоробки и костыли хоть гугловские, хоть другие здесь не нужны.
Одно слово - Skia
А можно как-то узнать работает ли этот многопроцессный режим? ps показывает лишь один процесс. Так что хотелось бы узнать случилось ли что непредвиденное или у меня просто какое-то установлено несовместимое расширение.
about:support
Графа Multiprocess Windows.
Значение показывает (что не совсем очевидно), сколько из открытых окон работают в многопроцессном режиме.Можно также зафорсировать многпроцессный режим (на случай, если какое-то расширение не декларирует явно, что многопроцессность не поддерживается).
Нашёл -- отключено. Т.е. мне теперь удалять дополнения и смотреть что изменится?
Возможно можно просто отключить.
Ну не знаю на борту 32Гб памяти (сейчас без ssd)
Я бы не сказал что 32битной однопроцессорный ff тормозит! тормоза начинаются когда памяти 2,8Гб вроде съедает.Но это происходит после 150 вкладок (я особо)
Но много тех что использую я не поддерживают много процессность.
> Нашёл -- отключено. Т.е. мне теперь удалять дополнения и смотреть что изменится?Можно не удалять, а дизейблить. Теоретически можно грепнуть по расширениям (мультпроцессность декларируется в дескрипторе расширения), надо только найти, что и где грепать. Советую обратиться к документации или проще к гуглу.
Многопроцессность включается так
browser.tabs.remote.autostart*=true
browser.tabs.remote.force-enable=true // создать параметр
dom.ipc.processCount=20И это работало начиная с релиза 47.
Процессы появились. Посмотрим что из этого выйдет.
Посмотри в about:support
А сколько оно будет жрать памяти, почему не говорится? Это ж по сути, как во времена IE6 - открываются отдельные окна, а не вкладки, но тут эти окна замаскированы под типа вкладки. Смысл вкладок тогда? Деградация полнейшая
Держи пруф (http://imgur.com/r0k5hEh) на классических 10 вкладок. По периодическому наблюдению, после того, как включил многопроцессорность жрать стало больше на 15-25%. Но при этом значительно улучшилась отзывчивость и скорость загрузки страниц. По крайней мере я ещё не разу не видел, чтобы страница грузилась по минуте или чтобы браузер колом встал (что ранее бывало).
Поэтому ИМХО наоборот не деградация, а прогресс и существенный.
Вероятно, далеко не все готовы променять прирост производительности на заметное увеличение потребления памяти.
>>на заметное увеличение потребления памяти
>15-25%Ну-у... В наше-то время ~100MiB сложно назвать критичным количеством.
Говорите за себя. У меня 4 гб и мне не хватает. Больше вставить нет возможности просто.
И сотня метров спасла бы отца русской демократии?
> И сотня метров спасла бы отца русской демократии?фокс жрёт 3-5 гигов, 25% от 5 гигов и меня бы спасли
меня вполне бы устроил один процесс на отрисовку интерфейса и один на обработку вкладок
можно вторых по штуке на окно (не на вкладку)
можно такое устроить с помощью настроек ?
>3-5 гиговХм. Ну хрен его знает. Я с таким не сталкивался. У меня редко перелезает сверх 300-400МиБ. Может тебе стоит какой-то адблокер поставить? Такие сумасшедшие числа явно сжираются каким-то дерьмом. Полезные вещи столько весить просто не могут. Во всяком случае в вебе.
Рисунок 1 - https://yadi.sk/i/N2XLCRXA34QNER
103 запроса, 2427 КБ, 4.48 сек.Рисунок 2 - https://yadi.sk/i/YCTFYXWm34QNFU
247 запросов, 7382 КБ, 43.15 сек.Ощутили куда уходит ваша память? Если ощутили, начинайте фильтровать.
то есть есть Юблок тормозит Лису?
А!) Увидел, все в порядке, Юблок наоборот дает ускорение)
У меня 4 гига рамы жрётся на 50 открытых вкладках. В принципе, если кому интересно, по опыту могу сказать, что некоторое снижение потребления памяти достигается табгруппами. В старых версиях они по умолчанию есть, в новых (уж не помню, после какой версии) - в виде аддона.
без приведенного списка дополнений эта информация не несет никакой полезной нагрузки
Поставьте себе zram и сделайте в нем сжатый swap,
только этим пока и спасаюсь.
4G ща дико недостаточно для работы FF и 10 вкладок.не знаю куда катится мир
наверное Вы и к деньгам так же относитесь, да?
> наверное Вы и к деньгам так же относитесь, да?Я с деньгами я очень аккуратен и бережлив. Поэтому у меня не четыре гигабайта RAM как у того страдальца выше, а тридцать два, и я с большим удовольствием поменяю 25% увеличение потребления памяти фаерфоксом на скорость его работы.
Кто не готов идут на lynx!
Остальные пруцца.
Тут надо смотреть с другой стороны. Вчера попробовал новый режим зафорсить в Firefox 50 на древнем нетбуке, так Firefox на нём стал работать заметно быстрее Chromium при меньшем потреблении памяти. Прирост быстродействия по меньшей мере 2-кратный. С давних пор Firefox на этом железе был просто неюзабелен.
> Держи пруф (http://imgur.com/r0k5hEh) на классических 10 вкладок. По периодическому наблюдению,
> после того, как включил многопроцессорность жрать стало больше на 15-25%. Но
> при этом значительно улучшилась отзывчивость и скорость загрузки страниц. По крайней
> мере я ещё не разу не видел, чтобы страница грузилась по
> минуте или чтобы браузер колом встал (что ранее бывало).
> Поэтому ИМХО наоборот не деградация, а прогресс и существенный.С таким успехом я мог окна пооткрывать. Смысл вкладок тогда? Спасибо, что подтвердил прожорливость. А отзывчивость меня и так устраивала. В топку это г*, надеюсь, будет отключаемая
> А сколько оно будет жрать памяти, почему не говорится? Это ж по сути, как во времена IE6 - открываются отдельные окна, а не вкладки, но тут эти окна замаскированы под типа вкладки. Смысл вкладок тогда? Деградация полнейшаята это у тебя в мышлении деградация полнейшая.
сказано же - раздельные процессы для гуя, скриптов, парсинга DOM-дерева и т.п., в зависимости от потребности!
в случае с ИЕ6, раздельными окнами и т.п. мы имеем 20 окон = 20 процессов, каждый из которых и гуй рисует и скрипты исполняет и все остальное делает.
тут же будет, по-идее, баланс: гуй рисует один процесс, скрипты исполняют несколько (зависит от кол-ва вкладок и кол-ва скриптов), определенное кол-во на плагины и т.п. - балансировка нагрузки это называется и масштабирование, юноша!
А вот зачем они разные то? Чтоб все время проверять тот ли дескриптор у процесса, чтоб городить огород с разделяемой памятью, чтоб менеджер процессов почаще переключал их контекст - и это все с целью сделать так, чтоб если умер процесс редеринга процессы парсеров страниц продолжали работать, работать и работать... ?
Что бы ни предпринимали мозилловцы -- а тормозит безбожно. Не вижу смысла файрфокса в 2017 году. Его времена прошли вместе с IE 6.
> Что бы ни предпринимали мозилловцы -- а тормозит безбожно. Не вижу смысла файрфокса в 2017 году. Его времена прошли вместе с IE 6.Ваши рекомендации? Какой из СОВРЕМЕННЫХ браузеров не тормозит и память не жрет безбожно по Вашему мнению? Ну, кроме lynx/links/elinks :)
>> Что бы ни предпринимали мозилловцы -- а тормозит безбожно. Не вижу смысла файрфокса в 2017 году. Его времена прошли вместе с IE 6.
> Ваши рекомендации? Какой из СОВРЕМЕННЫХ браузеров не тормозит и память не жрет
> безбожно по Вашему мнению? Ну, кроме lynx/links/elinks :)А нету современных браузеров, кроме двух, а судя по сему посту кроме одного, ибо Firefox подражает Хромому и скатывается на тот же уровень
Любой современный браузер будет жрать кучу памяти, ЛИБО будет тормозить как фаерфокс. Суть такова, что это не браузеры кривые, а HTML - убогий язык разметки.
Выделение отдельных процессов требует больше памяти, взамен получаем более гладкую работу интерфейса.
Я лично за многопроцессность.
Ждем, когда выделят расширения в отдельный процесс и допилят WebExtension API
> Выделение отдельных процессов требует больше памяти, взамен получаем более гладкую работу
> интерфейса.
> Я лично за многопроцессность.
> Ждем, когда выделят расширения в отдельный процесс и допилят WebExtension APIДа чё уж там, давай на каждый пук - новый процесс делать. На каждый dll и картинку по процессу. Вот это прогресс!
> На каждый dll и картинку по процессу.Палимся?
Кстати, для вантузоводов: Shared Оbject или Dynamic Link Library, запускаемые в отдельном процессе уже есть - это просто прочие бинарники-экзешники.
Хотя мы ваши негодования где-то в чем-то и понимаем - процессы в окошках создаются раз в 200-300 дольше потоков ).
Пятнадцать лет ждём разделяемую библиотеку libxul для общего использования кода между Firefox и Thunderbird. А воз и ныне там.
>Пятнадцать лет ждёмДля BSD-шников это разве срок?
>>Пятнадцать лет ждём
> Для BSD-шников это разве срок?А вот и вантузятнеги подтянулись. Опять еdge с аутглюком пиарить будем?
Я в ваших убунтоидных вендорлоках не разбираюсь. Брысь...
Не беспокойтесь, уже «скоро» XUL выкинут и ждать будет уже нечего.
Вместе с тандербёрдом.
И вместе с файрфоксом, я надеюсь.
Симанка спасет отца русской демократии.
> Симанка спасет отца русской демократии.Если падает браузер, то падает и почтовик - плавали, знаем!
Не так давно была xulrunner (уже закопанная) - не оно?
> Не так давно была xulrunner (уже закопанная) - не оно?Не совсем. Им нужна просто либа и чтоб фокс с птичкой пользовались общей её копией в памяти, а не грузили каждый свою.
> для общего использования кода между Firefox и ThunderbirdСиманка.
> По тестам Mozilla на многоядерных системах наблюдается увеличение отзывчивости интерфейса на 400% и ускорение загрузки страниц на 700%.Знаете за что я не люблю обозначение изменений в процентах? Их сложно правильно понять. Увеличение отзывчивости "на 400%" это в 4 или 5 раз быстрее? Скажем есть 100% чего-то, 400% от чего-то это в 4 раза больше чего-то… но "на" подразумевает сложение и 100% чего-то + 400% того же самого это уже 500%. Исходя из моих знаний английского перевод тут правильный и это таки в 5 и 8 раз быстрее. Так ведь?
А какая разница? Всё равно абсолютных чисел нет и что в 5 раз, что в 4 -- одинаково.
А знаете за что я не люблю обозначение изменений в разах в русском языке? За то что 200% это почему-то «в два раза», а не «в один». 300% это «в 3 раза», хотя логически «в два» от изначального числа.
>За то что 200% это почему-то «в два раза»А сколько? 100% это 1. 200% это 2. 150% это 1.5. 70% это 0.7. Что не так?
> 100% это 1. 200% это 2. 150% это 1.5. 70% это 0.7. Что не так?Всё так. Не так то, что 200% это увеличение «в два раза». А что такое увеличение в один раз? Ничего, это типо не увеличение, а умножение на 1.
Я говорю что лучше бы так: было 100, добавили ещё столько же (в итоге 200), увеличили «в один раз». Было 100, стало 300, увеличили в 2 раза. Было 100, стало 400, увеличили в 3 раза.
Эх, видать тебя в детстве обижали, когда делили яблоки и апельсины.
>Всё так. Не так то, что 200% это увеличение «в два раза». А что такое увеличение в один раз? Ничего, это типо не увеличение, а умножение на 1.
>Я говорю что лучше бы так: было 100, добавили ещё столько же (в итоге 200), увеличили «в один раз». Было 100, стало 300, увеличили в 2 раза. Было 100, стало 400, увеличили в 3 раза.Батенька, завязывайте с лизергиновой. А то у Вас с математикой и русским языком, как у того сына официанта из анекдота.
Мне кажется или вы путаете сложение с умножением? «В N раз» и «N% от» это умножение, на N[%] больше — сложение. Т.е. «на 20%» и «120% от» обозначают одно и то же. Просто указывать увеличение скорости аддитивно… несколько странно. Дело в том, что на самом деле ведь происходит не умножение, а деление. Ранее затрачивалась единица времени, а теперь её пятая часть. Т.е. в 5 раз быстрее это 1/5 времени, требовавшегося ранее, а вот «на 400% быстрее» это та же 1/5, но зачем-то записанная как 1/(1+4).Впрочем, мой вопрос заключался в том правильно ли я понял англоязычный оригинал статьи. Имеется ли там в виду аддитивные проценты так же, как и в русском переводе?
в один это ×1
200% (если от старого значения) это ×2
если на 200%, то ×3
чего это вы глупости пишете?
Вот берём единицу. Единица это не «в один», это изначальное число. Принято что увеличение до 2 называть «в два раза». Я лишь говорю, что логичнее было бы начинать с единицы, и называть увеличение с 1 до 2 и с 100 до 200 «в один раз». Потому что увеличилось в один раз.
Можете сравнить мои мысли с предложением всё считать с нуля, как в программировании. Только последнее явно не удобно в жизни, а моё вроде нет.
нет, «в один» это и есть «в один», данная конструкция не применяется в силу отсутствия какого-либо смысла, не более того
«в один раз» это ×1
Ваше предложение граничит с шизофренией
300% это "в три раза", потому что если 100 умножить на 3, будет 300, а не 400.
Дожили, на опеннете арфиметику четыре человека школьнику объясняют...
> отзывчивости интерфейса на 400% и ускорение загрузки страниц на 700%Я бы сказал, если такие четко круглые цифры в подобных вещах, то их вообще не стоит особо серьезно и точно воспринимать.
Барахло этот многопроцессный режим.
Во-первых, он жутко глючный. Так, в нём не работает Ctrl+U, а сам браузер крашится при попытке сохранения картинки с перегруженных графикой ресурсов (некоторых имиджбордов).
Во-вторых, не решена главная проблема - блокирование пользовательского интерфейса во время тяжеловесных операций вроде парсинга DOM или скриптов. Мне плевать, что странички теперь грузятся на сколько-то там процентов быстрее, если во время этой загрузки я не могу даже между вкладками переключаться, не говоря уж о том, чтоб закрыть внезапно подвисшую вкладку.
Да что закрыть, тут всё ещё прорисовка UI на время перестаёт работать, если парсится что-то суровое, к примеру http://dragons-world.wikia.com/wiki/Eggs
Уже сейчас можно накидать кучу ссылок на тяжеловесные ресурсы, которые буквально убивают Firefox, т.к. Mozilla в XXI веке всё ещё не в состоянии создать неблокирующийся интерфейс.
В итоге браузер представляет собой тормозильницу, ибо что там под капотом за быстродействие - то можно замерить лишь в специальных тестах, а вот что при любом действии сидим и курим, пока UI просрётся - это заметно всем и каждому. Итого народ всё быстрее бежит на Хром, а в Mozilla похоже даже не понимают, почему.
> Барахло этот многопроцессный режим.Так и есть. Он ещё очень далёк от завершения. Сейчас сделали просто основу под изменения, которые планируют реализовать в дальнейшем. Естественно что-то упустили и появились новые баги.
В 50 лисе вкладки стали каждый раз при переходе заново прорисовываться, вроде для экономии памяти. Как этого избежать? Не подскажите?
Избежать появления файрфоксовых вкладок. Тогда ваша проблема не возникнет в принципе.
Абсолютно не чувствую разницы что с e10s, что без. Единственное, с e10s появляется еще процессы лисы которые жрут память. А так прироста производительности не вижу.
да и не должно быть никакого прироста. разве что при перепиливании на процессы убрали какие-нибудь архитектурные тормоза заодно.
> да и не должно быть никакого прироста. разве что при перепиливании на
> процессы убрали какие-нибудь архитектурные тормоза заодно.А пишут что должно было
>и заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения неблокирующих друг друга операций. По тестам Mozilla на многоядерных системах наблюдается увеличение отзывчивости интерфейса на 400% и ускорение загрузки страниц на 700%И какой смысл сейчас в этом e10s, кроме задела на будущее если они на Servo переходить будут? Если бы я увидел хотя бы ускорение в 2 раза тогда понятно, а так только память лишнюю жрет.
>>и заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения неблокирующих друг друга операций. По тестам Mozilla на многоядерных системах наблюдается увеличение отзывчивости интерфейса на 400% и ускорение загрузки страниц на 700%так в том-то и фишка - что разницы нет. точнее потоки могут быть быстрее, чем процессы. почитай про архитектуру реализации потоков и процессов.
+ от закладывания процессов (а не потоков) - безопасность, архитектурный подход, устранение блокировок, ну и все такое. что может косвенно привести к повышению производительности.
Выставил 6 процессов, 5 часов в инете, я рад за Лису, хорошо кушает и не тормозит, а память это расплата за стабильность и скорость:)
https://s30.postimg.org/5pkonxym9/e10s.png
а чем многопроцессность отличается от много потоковости по-сути? разве что на каких-то архитекутрах.
Разница? Одно виртальное адресное пространство или несколько.
речь о производительности. напрямую с адресным пространством оно не работает, работает через кучу. с точки зрения производительности разницы не будет. точнее потоки должны быть пошустрей.
Поздно, я уже свалил чего и всем желаю.
Эх, а ведь Мозилла так старалась успеть, чтоб ты остался... :(
И на что перешли если не секрет?