Pull to refresh

Comments 50

Правда, что-то я мало заметил эффект. По крайней мере, «на глаз» всё те же подвисания мерзкие при загрузке тяжёлой страницы
Скорее всего настройка просто не активировалась по каким-то причинам. Я попробовал на Firefox 45 включить browser.tabs.remote.autostart — но судя по всему, оно не включилось (никаких дополнительных процессов не появилось). Возможно, оно определяет наличие несовместимых дополнений и молча не включает эту фишку.
browser.tabs.remote.autostart — стоит в 44 стабильной, ее можно скинуть на поток в бету, отключив обновления браузера, тем самым использовать стабильную версию лисы + пользоваться фишками беты)

browser.tabs.remote.autostart.1
browser.tabs.remote.autostart.2
применимы на 45 бета, но там сейчас уйма проблем с видео, неправильно кеширует содержимое, и может тормозить разное HD
Вот потому что вы такой химией занимаетесь, у вас и кеширование не работает, и видео тормозит. :)

Я щас на 45, 46 и 47 на разных машинах, единственная проблема — регрессия в 47 с загрузкой файлов.
та нет) кеш работает отлично в 44, но 45 и 46 под debian сливают их параллельно (вместо одного потока на видео их 2 или 3 и все одновременно), может с железом что то не то, но компиляция с флагами из mozilla
Спасибо за подсказку. Для всех трёх опций поставил true. Появился ещё один plugin-container.exe.
image

Мои расширения не отвалились (по крайней мере не заметил такого). Потестировал и немного расстроен.
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
А ведь ФФ был последним нормальным браузером, который не спавнил 100500 процессов, и жрал память в разумных пределах, а не как Хром. Очень жаль, я теперь даже не знаю, на какой браузер переходить.

P. S. Наверное, не мультипроцессорный, а мультипроцессный?
Так это реально проблема. Я вообще не знаю что с ним под линуксом случилось, но если в хроме вс ненормально загружаемых то FF визуально в 10 раз хуже работает, и почему то у меня лично CSS анимации с какими то артефактами идут.
Под Линуксом я редко ФФ пользуюсь, а вот под виндой я как раз с браузере провожу очень много времени, и пожаловаться не на что.
Что-то с аппаратным ускорением, похоже. Попробуйте его отключить на обоих.
Пока всё настраивается.
Для хрома есть удобное раширение The Great Suspender, выгружающее фоновые табы из памяти.
>многопроцессорный
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.

> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.

> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
multithreaded это всё же совсем не то, что многопроцессный.
Треды — в пределах одного процесса. Один тред упал = упало всё приложение.
(хотя по существу, видимо, всё же многопоточность. Покуда речь об устранении подтормаживания за счёт распараллеливания, а не об увеличении стабильности. Т.е. неважно, крутятся ли эти дополнительные треды в том же процессе, или в другом)

jank — это скорее «подтормаживание». Когда из-за проблем «внутри» начинает тупить интерфейс. В общем-то, это и есть «подвисание», только кратковременное, но при этом периодически возникающее.
Я бы вообще сказал бы многопоточный.
UFO landed and left these words here
Да. Будет переход на WebExtensions API.
UFO landed and left these words here
это ппц но похоже на то. Я вот не понимаю, какой смысл от одинаковых API для расширений в разных браузерах? Смысл тогда в разных браузерах?
Разницы не заметил.
Вообще, при переходе с 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 слишком уж сильно завязан с механизмами плагинов/дополнений, так что практически не поддаётся отделению. Отсюда и их последнее решение отказаться от старого механизма дополнений, т.к. там проще выкинуть всё и переписать заново, чем как-то отрефакторить.
Вообщем из всего прочитанного понял одно: надо сжалиться над разрабами ФФ и переходить на хром. Тот самый случай когда большинство пользователей, в своем бесхистростном порыве забить на тормозящие браузеры, реально правы.
Таков груз совместимости у Firefox. Весь JS работает в один поток. Абсолютно весь. JS всех вкладок и самого интерфейса браузера. Вот от этого и собираются много лет отказаться, но это ломает совместимость с большинством расширений. Поэтому и тянут так долго.
Простите. Забыл кусок текста, так как сам постоянно в бете)

Внимание.Применимо на всех версиях выше 44 на канале обновления «beta». Дело в том что часть кода новых функций просто напросто не будет на Firefox с каналом обновления иным от beta или developer, в целях сохранения стабильности.
Для изменения канала обновления нужно заменить строку «realise» на «beta» в файле channel-prefs.js. Файл расположен в вашей папке :Firefox/defaults/pref
А я вот никак не дождусь поддержки Ctrl+Tab в Хроме. Сильно не хватает.
Infotomb лежит второй день, перезалил на YouTube.
UFO landed and left these words here
странно, какая версия лисы?
~170 вкладок, большинство спят, всё вместе занимает ~1.2GB RAM, отзывчивость отличная:
image
От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет; ну есть процесс Web Content, который жрёт памяти примерно на равных с основным — но я его вроде видел и раньше. Так что это не многопроцессность, как в Chrome, а либо двупроцессность, как в Safari (Safari + Webkit2WebProcess), либо просто добавили многопоточность, а настоящую многопроцессность завезут аж с переходом на Servo. Сижу на альфа-ветке (Aurora; из официальных билдов, поговаривают, эту ветку уже выкинули, но на packages.debian.net по-прежнему есть), пробовал включать ещё с 42, тогда жуткий глюкодром был; сейчас 45, в целом юзабельно, хоть и некоторые расширения отвалились, но в однопроцессном режиме лучше.
«От многопроцессности на немощном железе только рассинхрон при переключении вкладок между интерфейсом и вьюпортом появился, а так никаких видимых принципиальных изменений. И настоящей многопроцессностью что-то не пахнет»
— вы не совсем правильно понимаете, собственно как и многие в чем разница.
«много процессный» — одинаковые по значению но независимые друг от друга процессы.
«мульти процессорный» — один процесс, асинхронно распределяет нагрузку на количество ядер распараллеливая поток как следствие нагрузку в целом, не выделяя: одна вкладка — один процесс.
Ситуация с firefox не такая как у chromium, упор сделан на не повторение ошибок и проблем с которыми сталкиваются пользователи второго, при этом не ограничивая а скорее расширяя возможность выбора.
По этому, на данный момент, лисичка не «многопроцессный», к счастью.

если слабое железо, то — нетребовательный софт, тем более — браузер.
программа всего лишь говорит что и как сделать, если железо не в состоянии справиться, то глупо требовать результат от софта
Измените заголовок на «многопроцессный», не путайте читателей!
и чем запутал? в анг. «мульти» и «много» синонимы, но применяются в разных значения, в данном — только «мульти». Получается firefox давно «многопроцессный», firefox + plugin container (уже 2, а значит много, достаточно относительно).То, о чем вы говорите это новый движок servo.
В оригинале (для примера возьмем любой) multi-process, multi-process = многопроцессный, а не «многопроцессорный» ваш заголовок звучит как будто добавили какую-либо оптимизацию специально для поддержки нескольких процессоров.
Спасибо что поправили. Только с утра понял о чем речь)
Автор, ты конфиг-то исправил в посте, молодец. Только я теперь не помню какие параметры на что менял. Дай старый конфиг, пожалуйста
только добавил browser.tabs.remote.autostart 1. 2 (true)
если не уверены в значениях сбросте (пкм на флаг, в меню сбросить)
Это конечно моё субъективное мнение – отключение SafeBrowsing плохая идея, точнее выиграшь от этого будет никакой, а когда никогда оно поможет.
Как это никакой? Гугл не будет палить все посещаемые сайты. Меньше левых запросов от браузера. Ещё какой профит.
Не так давно тестировал эту фичу. По мне пока она ещё очень сырая. Да, теперь интерфейс не виснет, но зато есть ощутимое снижение производительности при открытом окне разработчика (F12), а ещё XHR-запросы обрабатываются в разы медленнее.
Расширение Tab Tree конфликтует с параметром layers.acceleration.force-enabled = true: фон хрома перестаёт отрисовываться.
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention