LINUX.ORG.RU
ФорумTalks

Лиса перестанет тормозить из-за сборщика мусора

 ,


0

2

Микрофризы в файрфоксе, которые многие путали с 12309 уберут.

>16-я версия браузера Firefox, релиз которой намечен на 9 октября, содержит серьёзное обновление движка JavaScript. Сборщик мусора перейдёт от стратегии «stop-the-world», когда на время уборки полностью замораживается работа скриптов, к инкрементальной стратегии, когда сборка мусора происходит в несколько этапов. Хотя в целом работа сборщика мусора будет отнимать немного больше времени, отзывчивость браузера существенно улучшится, так как элементы интерфейса, анимация и игры не будут больше подвисать на несколько сотен миллисекунд на время уборки.

!Ъ: http://habrahabr.ru/post/150919/

По ссылке уже можно скачать какие-то бета-версии и что-то потестить.
Кто хочет увидить фризы вживую: http://people.mozilla.org/~wmccloskey/incremental-blog/example-pause.html (показывает задержку между кадрами)

★★★★★

Ответ на: комментарий от Eddy_Em

Общие — в плане один и тот же код, используемый разными веб-страницами

Если потоки с общими данными, то значит будет shared-буфер, доступный для чтения/записи всем потокам. Значит нужна система блокировок между тредами и сборщик мусора для shared-буфера отдельным потоком. Но этот подход обычно выливается в ещё бОльшие тормоза из-за постоянных взаимных блокировок. Ну и дополнительные накладные расходы на RAM/CPU. В общем, получится либо кривой тормозной велосипед, либо джава.

Другой подход - share-nothing архитектура, когда нет разделяемого буфера. Т.е. как у хрома. Её минус - одинаковые данные дублируются между процессами, т.е. требуется больше RAM и memcpy() для передачи любых данных между потоками процессами.

Mozilla servo - третий подход к распаралеливанию. Вместо жирных процессов (одна вкладка - один процесс) используется модель акторов, т.е. множество мелких легковесных потоков, которые будут совместно участвовать в рендере. Но для этого нужно переписать весь браузер с нуля на соотв. ЯП.

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Писал один студент систему функ. тестов для сервака с неким js-движком. После него глянули в код, за голову схватились (голову студента) :) Пусть даже движок идеологически однопоточен, а прога-то нет: у IO-фреймворка куча своих воркеров и на приеме сообщений спецэффекты от записи пустого указателя на буфер перекрывали любую «логику», идеологически обосновывающую отсутствие блокировок в обертках js-вызовов.

slackwarrior ★★★★★ ()
Ответ на: комментарий от xorik

Чтоб на многопроцессорной системе работало быстрее и не нагружая одно ядро

Ггг. А причем тут отдельные процессы? Да и многопоточность в случае io не всегда ведет к приросту скорострельности.

slackwarrior ★★★★★ ()
Ответ на: комментарий от xorik

Я тебе больше скажу, он юзает только 1 ядро процессора на все вкладки

Иногда мне кажется, что это хорошо. Аппаратное ограничение ресурсов для firefox :D

router ★★★★★ ()
Ответ на: комментарий от xorik

Это из-за requestAnimationFrame, которая ещё только черновик, а тут даже костыль не приставили (хотя хз, оно могло убить идею теста). Собственно из-за такого кода скрипты и не работают в {browser_name}.

Kalashnikov ★★★ ()
Ответ на: комментарий от Eddy_Em

ЕМНИП что то писали что есть в планах и не в таких уж отдаленных.

Behem0th ★★★★★ ()
Ответ на: комментарий от stevejobs

ЕМНИП было чтото в анонсах лисы что они «скорость обработки» вкладки снижают если она не активна.

Behem0th ★★★★★ ()
Ответ на: комментарий от x_hash

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

У лисы уже давно плагинконтейнер отдельным процессом.

Behem0th ★★★★★ ()

Сборщик мусора перейдёт от стратегии «stop-the-world», когда на время уборки полностью замораживается работа скриптов, к инкрементальной стратегии, когда сборка мусора происходит в несколько этапов. Хотя в целом работа сборщика мусора будет отнимать немного больше времени, отзывчивость браузера существенно улучшится

да неужели в мозилле наконец-таки осилили книжку Кнута написанную в середине прошлого века!

drBatty ★★ ()
Ответ на: комментарий от andreyu

Вообще не понял, что там показывают.

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

drBatty ★★ ()
Ответ на: комментарий от xorik

А почему разработчики хрома юзают процессы вместо тредов?

потому-что

1. идиоты

2. венда не умеет нормально работать с нитями, потому FF в венде работает намного хуже (если много вкладок и много ядер). Это я наблюдал на WinXP, на семёрке вроде получше (или просто более новый CPU вытягивает так, что лаги незаметны). Т.к. большая часть (95%) хомячков юзают именно WinXP, то и получается, что с их т.з.: хром рулит, фф гуано.

Такие дела.

drBatty ★★ ()
Ответ на: комментарий от alpha4

4.2

А почему разработчики хрома юзают процессы вместо тредов?

сможешь ответить?

drBatty ★★ ()
Ответ на: комментарий от Eddy_Em

вариант

остается придумать что делать в случае когда userscript поменял часть скрипта который есть «общий»

ZuBB ★★★★★ ()
Ответ на: комментарий от alpha4

блин, я не говорю, что венда «не умеет», умеет. Только там всё через задницу реализовано. Линуксовая версия тоже открывает и процессы и нити:

+-chrome-+-chrome
     |          |      |        |-chrome---2*[{chrome}]
     |          |      |        |-chrome-sandbox---chrome---chrome-+-3*[chrome---3*[{chrome}]]
     |          |      |        |                                  `-chrome---30*[{chrome}]
     |          |      |        `-32*[{chrome}]
при этом ФФ - только нити
firefox---22*[{firefox}]

drBatty ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.