Comments 50
Спасибо!
0
Правда, что-то я мало заметил эффект. По крайней мере, «на глаз» всё те же подвисания мерзкие при загрузке тяжёлой страницы
+1
Скорее всего настройка просто не активировалась по каким-то причинам. Я попробовал на Firefox 45 включить browser.tabs.remote.autostart — но судя по всему, оно не включилось (никаких дополнительных процессов не появилось). Возможно, оно определяет наличие несовместимых дополнений и молча не включает эту фишку.
0
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
0
Вот потому что вы такой химией занимаетесь, у вас и кеширование не работает, и видео тормозит. :)
Я щас на 45, 46 и 47 на разных машинах, единственная проблема — регрессия в 47 с загрузкой файлов.
Я щас на 45, 46 и 47 на разных машинах, единственная проблема — регрессия в 47 с загрузкой файлов.
0
Спасибо за подсказку. Для всех трёх опций поставил true. Появился ещё один plugin-container.exe.
Мои расширения не отвалились (по крайней мере не заметил такого). Потестировал и немного расстроен.
1. Процесс рендеринга имеет Integrity=Medium, то есть он всё ещё имеет кучу прав, и в случае взлома браузера от имени этого процесса всё ещё можно натворить дел без сопротивления со стороны ОС. То есть цель «повысить безопасность» по крайней мере в 45b1 пока что не выполняется.
2. Запустил тяжёлую страницу с длинным циклом, который подвешивает страницу на несколько секунд. Браузер тоже почему-то подвис, как и без вынесения выполнения страниц в отдельный процесс.
Возможно, из-за обилия расширений у меня включился какой-то режим совместимости, который заставляет UI браузера работать синхронно со страницами, имитируя старое однопоточное выполнение всего JS на страницах и в интерфейсе браузера. Это просто предположение, точно я не знаю. Будем ждать релиза этой возможности и оценивать уже окончательный вариант.
Мои расширения не отвалились (по крайней мере не заметил такого). Потестировал и немного расстроен.
1. Процесс рендеринга имеет Integrity=Medium, то есть он всё ещё имеет кучу прав, и в случае взлома браузера от имени этого процесса всё ещё можно натворить дел без сопротивления со стороны ОС. То есть цель «повысить безопасность» по крайней мере в 45b1 пока что не выполняется.
2. Запустил тяжёлую страницу с длинным циклом, который подвешивает страницу на несколько секунд. Браузер тоже почему-то подвис, как и без вынесения выполнения страниц в отдельный процесс.
Возможно, из-за обилия расширений у меня включился какой-то режим совместимости, который заставляет UI браузера работать синхронно со страницами, имитируя старое однопоточное выполнение всего JS на страницах и в интерфейсе браузера. Это просто предположение, точно я не знаю. Будем ждать релиза этой возможности и оценивать уже окончательный вариант.
0
проверьте так, запустите браузер в «приватном режиме», там реально увидите как работают внесенные изменения (проблема возможно, а так скорее всего и есть — в дополнениях), лично у меня отзывчивость такая же как у хрома, хотя железо нетбук asus eee pc 1011px 2gb, и никаких задержек при открытии сразу, более 20 вкладок, прорисовывает и отзывается.Схема описанная проверена много раз, лично.
-1
Простите. Забыл кусок текста, так как сам постоянно в бете)
Внимание.Применимо на всех версиях выше 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
0
А ведь ФФ был последним нормальным браузером, который не спавнил 100500 процессов, и жрал память в разумных пределах, а не как Хром. Очень жаль, я теперь даже не знаю, на какой браузер переходить.
P. S. Наверное, не мультипроцессорный, а мультипроцессный?
P. S. Наверное, не мультипроцессорный, а мультипроцессный?
+12
Так это реально проблема. Я вообще не знаю что с ним под линуксом случилось, но если в хроме вс ненормально загружаемых то FF визуально в 10 раз хуже работает, и почему то у меня лично CSS анимации с какими то артефактами идут.
0
Пока всё настраивается.
0
Для хрома есть удобное раширение The Great Suspender, выгружающее фоновые табы из памяти.
+1
>многопроцессорный
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.
> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.
> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.
> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.
> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
+8
multithreaded это всё же совсем не то, что многопроцессный.
Треды — в пределах одного процесса. Один тред упал = упало всё приложение.
(хотя по существу, видимо, всё же многопоточность. Покуда речь об устранении подтормаживания за счёт распараллеливания, а не об увеличении стабильности. Т.е. неважно, крутятся ли эти дополнительные треды в том же процессе, или в другом)
jank — это скорее «подтормаживание». Когда из-за проблем «внутри» начинает тупить интерфейс. В общем-то, это и есть «подвисание», только кратковременное, но при этом периодически возникающее.
Треды — в пределах одного процесса. Один тред упал = упало всё приложение.
(хотя по существу, видимо, всё же многопоточность. Покуда речь об устранении подтормаживания за счёт распараллеливания, а не об увеличении стабильности. Т.е. неважно, крутятся ли эти дополнительные треды в том же процессе, или в другом)
jank — это скорее «подтормаживание». Когда из-за проблем «внутри» начинает тупить интерфейс. В общем-то, это и есть «подвисание», только кратковременное, но при этом периодически возникающее.
0
Я бы вообще сказал бы многопоточный.
0
UFO just landed and posted this here
Разницы не заметил.
Вообще, при переходе с 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, переваривают вышеприведённый пример без малейших проблем.
+5
ой да ладно Вам, сделать для JS отдельный процесс как уже сделали в свое время для плагинов и все будет замечательно
0
Это не решит проблему. Вынесут в отдельный поток JS — будет тормозить за счёт, к примеру css, на котором сейчас тоже можно FF подвесить и который так развился, что мне даже попадались игры, написанные без единой строчки JS.
Вынесут CSS — будет тормозить парсинг. Или загрузка. Или обработка сложных изображений, тут особенно svg с кучей фильтров отличается.
Поэтому выносить нужно в первую очередь UI. Пользователь должен скроллить, переключать вкладки, лазить по меню без малейших подтормаживаний, даже если всё остальное подвисло. И должен иметь возможность закрыть любую вкладку, если она ушла в глубокую задумчивость.
Вынеся в отдельный поток UI, мы тем самым заметаем проблему тормозов под ковёр — подтормаживания станут практически незаметными.
И в Mozilla это понимают. Но там код UI слишком уж сильно завязан с механизмами плагинов/дополнений, так что практически не поддаётся отделению. Отсюда и их последнее решение отказаться от старого механизма дополнений, т.к. там проще выкинуть всё и переписать заново, чем как-то отрефакторить.
Вынесут CSS — будет тормозить парсинг. Или загрузка. Или обработка сложных изображений, тут особенно svg с кучей фильтров отличается.
Поэтому выносить нужно в первую очередь UI. Пользователь должен скроллить, переключать вкладки, лазить по меню без малейших подтормаживаний, даже если всё остальное подвисло. И должен иметь возможность закрыть любую вкладку, если она ушла в глубокую задумчивость.
Вынеся в отдельный поток UI, мы тем самым заметаем проблему тормозов под ковёр — подтормаживания станут практически незаметными.
И в Mozilla это понимают. Но там код UI слишком уж сильно завязан с механизмами плагинов/дополнений, так что практически не поддаётся отделению. Отсюда и их последнее решение отказаться от старого механизма дополнений, т.к. там проще выкинуть всё и переписать заново, чем как-то отрефакторить.
+1
Таков груз совместимости у Firefox. Весь JS работает в один поток. Абсолютно весь. JS всех вкладок и самого интерфейса браузера. Вот от этого и собираются много лет отказаться, но это ломает совместимость с большинством расширений. Поэтому и тянут так долго.
+1
Простите. Забыл кусок текста, так как сам постоянно в бете)
Внимание.Применимо на всех версиях выше 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
0
А я вот никак не дождусь поддержки Ctrl+Tab в Хроме. Сильно не хватает.
0
А впрочем, лучше один раз увидеть, чем 100 раз прочитать.
Точно. Вот чистая лиса 45, и ничего этого не происходит.
0
UFO just landed and posted this here
От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет; ну есть процесс Web Content, который жрёт памяти примерно на равных с основным — но я его вроде видел и раньше. Так что это не многопроцессность, как в Chrome, а либо двупроцессность, как в Safari (Safari + Webkit2WebProcess), либо просто добавили многопоточность, а настоящую многопроцессность завезут аж с переходом на Servo. Сижу на альфа-ветке (Aurora; из официальных билдов, поговаривают, эту ветку уже выкинули, но на packages.debian.net по-прежнему есть), пробовал включать ещё с 42, тогда жуткий глюкодром был; сейчас 45, в целом юзабельно, хоть и некоторые расширения отвалились, но в однопроцессном режиме лучше.
0
«От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет»
— вы не совсем правильно понимаете, собственно как и многие в чем разница.
«много процессный» — одинаковые по значению но независимые друг от друга процессы.
«мульти процессорный» — один процесс, асинхронно распределяет нагрузку на количество ядер распараллеливая поток как следствие нагрузку в целом, не выделяя: одна вкладка — один процесс.
Ситуация с firefox не такая как у chromium, упор сделан на не повторение ошибок и проблем с которыми сталкиваются пользователи второго, при этом не ограничивая а скорее расширяя возможность выбора.
По этому, на данный момент, лисичка не «многопроцессный», к счастью.
если слабое железо, то — нетребовательный софт, тем более — браузер.
программа всего лишь говорит что и как сделать, если железо не в состоянии справиться, то глупо требовать результат от софта
— вы не совсем правильно понимаете, собственно как и многие в чем разница.
«много процессный» — одинаковые по значению но независимые друг от друга процессы.
«мульти процессорный» — один процесс, асинхронно распределяет нагрузку на количество ядер распараллеливая поток как следствие нагрузку в целом, не выделяя: одна вкладка — один процесс.
Ситуация с firefox не такая как у chromium, упор сделан на не повторение ошибок и проблем с которыми сталкиваются пользователи второго, при этом не ограничивая а скорее расширяя возможность выбора.
По этому, на данный момент, лисичка не «многопроцессный», к счастью.
если слабое железо, то — нетребовательный софт, тем более — браузер.
программа всего лишь говорит что и как сделать, если железо не в состоянии справиться, то глупо требовать результат от софта
0
Измените заголовок на «многопроцессный», не путайте читателей!
0
()
0
Автор, ты конфиг-то исправил в посте, молодец. Только я теперь не помню какие параметры на что менял. Дай старый конфиг, пожалуйста
+1
sohabrahabr.ru/post/276321
Потыкайте в «сохранено».
Потыкайте в «сохранено».
0
только добавил browser.tabs.remote.autostart 1. 2 (true)
если не уверены в значениях сбросте (пкм на флаг, в меню сбросить)
если не уверены в значениях сбросте (пкм на флаг, в меню сбросить)
0
Это конечно моё субъективное мнение – отключение SafeBrowsing плохая идея, точнее выиграшь от этого будет никакой, а когда никогда оно поможет.
+1
Не так давно тестировал эту фичу. По мне пока она ещё очень сырая. Да, теперь интерфейс не виснет, но зато есть ощутимое снижение производительности при открытом окне разработчика (F12), а ещё XHR-запросы обрабатываются в разы медленнее.
0
Расширение Tab Tree конфликтует с параметром layers.acceleration.force-enabled = true: фон хрома перестаёт отрисовываться.
0
Sign up to leave a comment.
Многопроцессный Firefox 44.b, оптимизация Electrolysis