Комментарии 50
Спасибо!
Правда, что-то я мало заметил эффект. По крайней мере, «на глаз» всё те же подвисания мерзкие при загрузке тяжёлой страницы
Скорее всего настройка просто не активировалась по каким-то причинам. Я попробовал на Firefox 45 включить browser.tabs.remote.autostart — но судя по всему, оно не включилось (никаких дополнительных процессов не появилось). Возможно, оно определяет наличие несовместимых дополнений и молча не включает эту фишку.
browser.tabs.remote.autostart — стоит в 44 стабильной, ее можно скинуть на поток в бету, отключив обновления браузера, тем самым использовать стабильную версию лисы + пользоваться фишками беты)
browser.tabs.remote.autostart.1
browser.tabs.remote.autostart.2
применимы на 45 бета, но там сейчас уйма проблем с видео, неправильно кеширует содержимое, и может тормозить разное HD
browser.tabs.remote.autostart.1
browser.tabs.remote.autostart.2
применимы на 45 бета, но там сейчас уйма проблем с видео, неправильно кеширует содержимое, и может тормозить разное HD
Спасибо за подсказку. Для всех трёх опций поставил true. Появился ещё один plugin-container.exe.
Мои расширения не отвалились (по крайней мере не заметил такого). Потестировал и немного расстроен.
1. Процесс рендеринга имеет Integrity=Medium, то есть он всё ещё имеет кучу прав, и в случае взлома браузера от имени этого процесса всё ещё можно натворить дел без сопротивления со стороны ОС. То есть цель «повысить безопасность» по крайней мере в 45b1 пока что не выполняется.
2. Запустил тяжёлую страницу с длинным циклом, который подвешивает страницу на несколько секунд. Браузер тоже почему-то подвис, как и без вынесения выполнения страниц в отдельный процесс.
Возможно, из-за обилия расширений у меня включился какой-то режим совместимости, который заставляет UI браузера работать синхронно со страницами, имитируя старое однопоточное выполнение всего JS на страницах и в интерфейсе браузера. Это просто предположение, точно я не знаю. Будем ждать релиза этой возможности и оценивать уже окончательный вариант.
Мои расширения не отвалились (по крайней мере не заметил такого). Потестировал и немного расстроен.
1. Процесс рендеринга имеет Integrity=Medium, то есть он всё ещё имеет кучу прав, и в случае взлома браузера от имени этого процесса всё ещё можно натворить дел без сопротивления со стороны ОС. То есть цель «повысить безопасность» по крайней мере в 45b1 пока что не выполняется.
2. Запустил тяжёлую страницу с длинным циклом, который подвешивает страницу на несколько секунд. Браузер тоже почему-то подвис, как и без вынесения выполнения страниц в отдельный процесс.
Возможно, из-за обилия расширений у меня включился какой-то режим совместимости, который заставляет UI браузера работать синхронно со страницами, имитируя старое однопоточное выполнение всего JS на страницах и в интерфейсе браузера. Это просто предположение, точно я не знаю. Будем ждать релиза этой возможности и оценивать уже окончательный вариант.
проверьте так, запустите браузер в «приватном режиме», там реально увидите как работают внесенные изменения (проблема возможно, а так скорее всего и есть — в дополнениях), лично у меня отзывчивость такая же как у хрома, хотя железо нетбук asus eee pc 1011px 2gb, и никаких задержек при открытии сразу, более 20 вкладок, прорисовывает и отзывается.Схема описанная проверена много раз, лично.
Простите. Забыл кусок текста, так как сам постоянно в бете)
Внимание.Применимо на всех версиях выше 44 на канале обновления «beta». Дело в том что часть кода новых функций просто напросто не будет на Firefox с каналом обновления иным от beta или developer, в целях сохранения стабильности.
Для изменения канала обновления нужно заменить строку «realise» на «beta» в файле channel-prefs.js. Файл расположен в вашей папке :Firefox/defaults/pref
Внимание.Применимо на всех версиях выше 44 на канале обновления «beta». Дело в том что часть кода новых функций просто напросто не будет на Firefox с каналом обновления иным от beta или developer, в целях сохранения стабильности.
Для изменения канала обновления нужно заменить строку «realise» на «beta» в файле channel-prefs.js. Файл расположен в вашей папке :Firefox/defaults/pref
А ведь ФФ был последним нормальным браузером, который не спавнил 100500 процессов, и жрал память в разумных пределах, а не как Хром. Очень жаль, я теперь даже не знаю, на какой браузер переходить.
P. S. Наверное, не мультипроцессорный, а мультипроцессный?
P. S. Наверное, не мультипроцессорный, а мультипроцессный?
Так это реально проблема. Я вообще не знаю что с ним под линуксом случилось, но если в хроме вс ненормально загружаемых то FF визуально в 10 раз хуже работает, и почему то у меня лично CSS анимации с какими то артефактами идут.
Пока всё настраивается.
Для хрома есть удобное раширение The Great Suspender, выгружающее фоновые табы из памяти.
>многопроцессорный
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.
> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.
> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.
> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.
> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
multithreaded это всё же совсем не то, что многопроцессный.
Треды — в пределах одного процесса. Один тред упал = упало всё приложение.
(хотя по существу, видимо, всё же многопоточность. Покуда речь об устранении подтормаживания за счёт распараллеливания, а не об увеличении стабильности. Т.е. неважно, крутятся ли эти дополнительные треды в том же процессе, или в другом)
jank — это скорее «подтормаживание». Когда из-за проблем «внутри» начинает тупить интерфейс. В общем-то, это и есть «подвисание», только кратковременное, но при этом периодически возникающее.
Треды — в пределах одного процесса. Один тред упал = упало всё приложение.
(хотя по существу, видимо, всё же многопоточность. Покуда речь об устранении подтормаживания за счёт распараллеливания, а не об увеличении стабильности. Т.е. неважно, крутятся ли эти дополнительные треды в том же процессе, или в другом)
jank — это скорее «подтормаживание». Когда из-за проблем «внутри» начинает тупить интерфейс. В общем-то, это и есть «подвисание», только кратковременное, но при этом периодически возникающее.
Я бы вообще сказал бы многопоточный.
НЛО прилетело и опубликовало эту надпись здесь
Разницы не заметил.
Вообще, при переходе с Chrome на FF люди испытывают примерно те же чувства, что и при переходе с iOS на Android — всё никак не удаётся избавиться от чувства неповоротливости интерфейса, т.к. вне зависимости от количества памяти, ядер и гигагерц UI периодически подтормаживает — между вводом команды и её обработкой то и дело возникают вполне ощутимые задержки. Фанаты Android (и FF) давно к ним привыкли и даже не замечают, но при переходе с другой системы они ох как заметны для тех, кто привык к совсем другому уровню отзывчивости.
Причина в изначально кривой архитектуре. У пользовательского потока должен быть приоритет. Сперва обработай пользовательский ввод и прорисовку, а уж потом занимайся парсингом и прочими важными делами.
В Firefox же… А впрочем, лучше один раз увидеть, чем 100 раз прочитать. Создаём простейшую страничку вида:
и загружаем в FF, предварительно убедившись, что там не стоит NoScript, uMatrix и тому подобных плагинов, блокирующих JS. Результат потрясает в плохом смысле этого слова.
Браузер подвисает весь. Полностью. Вы не сможете ни переключить вкладку, ни закрыть только что открытую, ни выйти в меню браузера. Да что там меню, умирает даже поток прорисовки — если перекрыть окно FF чем-то ещё, изображение спокойно затирается. Всё, что вам остаётся — грустно смотреть на часы в ожидании появления окошка «этот сценарий не отвечает».
Да это же просто кошмар! Уже в начале 2000-х люди научились даже в одном процессе, даже в одном потоке ухитряться обрабатывать прорисовку и пользовательский ввод при выполнении каких-то тяжёлых вычислений. В простейшем случае достаточно воткнуть внутри основного рабочего цикла что-то вроде processMessages(); if (isStopButtonPressed) return 0;
Firefox в плане своей архитектуры так и остался в прошлом тысячелетии. И Chrome, и даже многократно обруганный MS Edge, переваривают вышеприведённый пример без малейших проблем.
Вообще, при переходе с Chrome на FF люди испытывают примерно те же чувства, что и при переходе с iOS на Android — всё никак не удаётся избавиться от чувства неповоротливости интерфейса, т.к. вне зависимости от количества памяти, ядер и гигагерц UI периодически подтормаживает — между вводом команды и её обработкой то и дело возникают вполне ощутимые задержки. Фанаты Android (и FF) давно к ним привыкли и даже не замечают, но при переходе с другой системы они ох как заметны для тех, кто привык к совсем другому уровню отзывчивости.
Причина в изначально кривой архитектуре. У пользовательского потока должен быть приоритет. Сперва обработай пользовательский ввод и прорисовку, а уж потом занимайся парсингом и прочими важными делами.
В Firefox же… А впрочем, лучше один раз увидеть, чем 100 раз прочитать. Создаём простейшую страничку вида:
<!doctype html>
<html>
<head></head>
<body>
<script>
do {} while (true);
</script>
</body>
</html>
и загружаем в FF, предварительно убедившись, что там не стоит NoScript, uMatrix и тому подобных плагинов, блокирующих JS. Результат потрясает в плохом смысле этого слова.
Браузер подвисает весь. Полностью. Вы не сможете ни переключить вкладку, ни закрыть только что открытую, ни выйти в меню браузера. Да что там меню, умирает даже поток прорисовки — если перекрыть окно FF чем-то ещё, изображение спокойно затирается. Всё, что вам остаётся — грустно смотреть на часы в ожидании появления окошка «этот сценарий не отвечает».
Да это же просто кошмар! Уже в начале 2000-х люди научились даже в одном процессе, даже в одном потоке ухитряться обрабатывать прорисовку и пользовательский ввод при выполнении каких-то тяжёлых вычислений. В простейшем случае достаточно воткнуть внутри основного рабочего цикла что-то вроде processMessages(); if (isStopButtonPressed) return 0;
Firefox в плане своей архитектуры так и остался в прошлом тысячелетии. И Chrome, и даже многократно обруганный MS Edge, переваривают вышеприведённый пример без малейших проблем.
ой да ладно Вам, сделать для JS отдельный процесс как уже сделали в свое время для плагинов и все будет замечательно
Это не решит проблему. Вынесут в отдельный поток JS — будет тормозить за счёт, к примеру css, на котором сейчас тоже можно FF подвесить и который так развился, что мне даже попадались игры, написанные без единой строчки JS.
Вынесут CSS — будет тормозить парсинг. Или загрузка. Или обработка сложных изображений, тут особенно svg с кучей фильтров отличается.
Поэтому выносить нужно в первую очередь UI. Пользователь должен скроллить, переключать вкладки, лазить по меню без малейших подтормаживаний, даже если всё остальное подвисло. И должен иметь возможность закрыть любую вкладку, если она ушла в глубокую задумчивость.
Вынеся в отдельный поток UI, мы тем самым заметаем проблему тормозов под ковёр — подтормаживания станут практически незаметными.
И в Mozilla это понимают. Но там код UI слишком уж сильно завязан с механизмами плагинов/дополнений, так что практически не поддаётся отделению. Отсюда и их последнее решение отказаться от старого механизма дополнений, т.к. там проще выкинуть всё и переписать заново, чем как-то отрефакторить.
Вынесут CSS — будет тормозить парсинг. Или загрузка. Или обработка сложных изображений, тут особенно svg с кучей фильтров отличается.
Поэтому выносить нужно в первую очередь UI. Пользователь должен скроллить, переключать вкладки, лазить по меню без малейших подтормаживаний, даже если всё остальное подвисло. И должен иметь возможность закрыть любую вкладку, если она ушла в глубокую задумчивость.
Вынеся в отдельный поток UI, мы тем самым заметаем проблему тормозов под ковёр — подтормаживания станут практически незаметными.
И в Mozilla это понимают. Но там код UI слишком уж сильно завязан с механизмами плагинов/дополнений, так что практически не поддаётся отделению. Отсюда и их последнее решение отказаться от старого механизма дополнений, т.к. там проще выкинуть всё и переписать заново, чем как-то отрефакторить.
Таков груз совместимости у Firefox. Весь JS работает в один поток. Абсолютно весь. JS всех вкладок и самого интерфейса браузера. Вот от этого и собираются много лет отказаться, но это ломает совместимость с большинством расширений. Поэтому и тянут так долго.
Простите. Забыл кусок текста, так как сам постоянно в бете)
Внимание.Применимо на всех версиях выше 44 на канале обновления «beta». Дело в том что часть кода новых функций просто напросто не будет на Firefox с каналом обновления иным от beta или developer, в целях сохранения стабильности.
Для изменения канала обновления нужно заменить строку «realise» на «beta» в файле channel-prefs.js. Файл расположен в вашей папке :Firefox/defaults/pref
Внимание.Применимо на всех версиях выше 44 на канале обновления «beta». Дело в том что часть кода новых функций просто напросто не будет на Firefox с каналом обновления иным от beta или developer, в целях сохранения стабильности.
Для изменения канала обновления нужно заменить строку «realise» на «beta» в файле channel-prefs.js. Файл расположен в вашей папке :Firefox/defaults/pref
А я вот никак не дождусь поддержки Ctrl+Tab в Хроме. Сильно не хватает.
А впрочем, лучше один раз увидеть, чем 100 раз прочитать.
Точно. Вот чистая лиса 45, и ничего этого не происходит.
НЛО прилетело и опубликовало эту надпись здесь
От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет; ну есть процесс Web Content, который жрёт памяти примерно на равных с основным — но я его вроде видел и раньше. Так что это не многопроцессность, как в Chrome, а либо двупроцессность, как в Safari (Safari + Webkit2WebProcess), либо просто добавили многопоточность, а настоящую многопроцессность завезут аж с переходом на Servo. Сижу на альфа-ветке (Aurora; из официальных билдов, поговаривают, эту ветку уже выкинули, но на packages.debian.net по-прежнему есть), пробовал включать ещё с 42, тогда жуткий глюкодром был; сейчас 45, в целом юзабельно, хоть и некоторые расширения отвалились, но в однопроцессном режиме лучше.
«От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет»
— вы не совсем правильно понимаете, собственно как и многие в чем разница.
«много процессный» — одинаковые по значению но независимые друг от друга процессы.
«мульти процессорный» — один процесс, асинхронно распределяет нагрузку на количество ядер распараллеливая поток как следствие нагрузку в целом, не выделяя: одна вкладка — один процесс.
Ситуация с firefox не такая как у chromium, упор сделан на не повторение ошибок и проблем с которыми сталкиваются пользователи второго, при этом не ограничивая а скорее расширяя возможность выбора.
По этому, на данный момент, лисичка не «многопроцессный», к счастью.
если слабое железо, то — нетребовательный софт, тем более — браузер.
программа всего лишь говорит что и как сделать, если железо не в состоянии справиться, то глупо требовать результат от софта
— вы не совсем правильно понимаете, собственно как и многие в чем разница.
«много процессный» — одинаковые по значению но независимые друг от друга процессы.
«мульти процессорный» — один процесс, асинхронно распределяет нагрузку на количество ядер распараллеливая поток как следствие нагрузку в целом, не выделяя: одна вкладка — один процесс.
Ситуация с firefox не такая как у chromium, упор сделан на не повторение ошибок и проблем с которыми сталкиваются пользователи второго, при этом не ограничивая а скорее расширяя возможность выбора.
По этому, на данный момент, лисичка не «многопроцессный», к счастью.
если слабое железо, то — нетребовательный софт, тем более — браузер.
программа всего лишь говорит что и как сделать, если железо не в состоянии справиться, то глупо требовать результат от софта
Измените заголовок на «многопроцессный», не путайте читателей!
и чем запутал? в анг. «мульти» и «много» синонимы, но применяются в разных значения, в данном — только «мульти». Получается firefox давно «многопроцессный», firefox + plugin container (уже 2, а значит много, достаточно относительно).То, о чем вы говорите это новый движок servo.
В оригинале (для примера возьмем любой) multi-process, multi-process = многопроцессный, а не «многопроцессорный» ваш заголовок звучит как будто добавили какую-либо оптимизацию специально для поддержки нескольких процессоров.
()
Автор, ты конфиг-то исправил в посте, молодец. Только я теперь не помню какие параметры на что менял. Дай старый конфиг, пожалуйста
sohabrahabr.ru/post/276321
Потыкайте в «сохранено».
Потыкайте в «сохранено».
только добавил browser.tabs.remote.autostart 1. 2 (true)
если не уверены в значениях сбросте (пкм на флаг, в меню сбросить)
если не уверены в значениях сбросте (пкм на флаг, в меню сбросить)
Это конечно моё субъективное мнение – отключение SafeBrowsing плохая идея, точнее выиграшь от этого будет никакой, а когда никогда оно поможет.
Не так давно тестировал эту фичу. По мне пока она ещё очень сырая. Да, теперь интерфейс не виснет, но зато есть ощутимое снижение производительности при открытом окне разработчика (F12), а ещё XHR-запросы обрабатываются в разы медленнее.
Расширение Tab Tree конфликтует с параметром layers.acceleration.force-enabled = true: фон хрома перестаёт отрисовываться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многопроцессный Firefox 44.b, оптимизация Electrolysis