похоже на то
с мультиком у меня сейчас 140 в основном процессе и 90 в контент
без мультика 100-120 с теми же вкладками
вероятно дополнительные потоки обрабатывают межпроцессное взаимодействие
javascript/dom в принципе однопоточны в рамках одной страницы, но это не значит что нельзя сделать каждую страницу в отдельном потоке
кстати сча глянул, в основном процессе 150 потоков, в контент процессе 70 потоков
при том что открыто всего с десяток табов в основном с простым контентом
что они там делают — одному б-гу известно %(
какие-то странные результаты мягко говоря
хром жрет меньше фф? хром 32битны жрет стока же как 64битны?
вот на мной взгляд заслуживающий больше доверия бенч http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ там получается дето на 30% больше у 64бит
возможность использования большего количества памяти при использовании меньшего количества памяти :)?
сомневаюсь что 64 битная версия даже 50% больше памяти использует, скорее 10-15%
как увеличение количества процессов может улучшить производительность?
все равно что от например сервлетов вернутся назад к CGI
думаю дело в том что разработчики браузеров не в состоянии осилить многопоточное программирование (что не удивительно учитывая на чем они пишут) и потому вынуждены вернуться к разделенной памяти
хром допустим хвалится тем что если одна страница упадет то другие останутся, а вот сделать так чтобы не падало — им не по силам
фаерфокс с другой стороны даже не заморачивается на выделение по процессу на страницу, отдельный процесс занимается рендерингом всех страниц, и падают они как и раньше все вместе
единственное что улучшилось — теперь если какая-то страница начинает педалить то интерфейс браузер остается отзывчивым, но непонятно почему нельзя было точно так же вынести рендеринг страниц в отдельный поток а не процесс
а вот глючный GC как был пять лет назад так и остался https://bugzilla.mozilla.org/show_bug.cgi?id=646941
после введения монеток время обслуживания на кассах существенно увеличилось, карманы стали тяжелей, а единственный аргумент от простых граждан который я слышал — вроде вашего — «прикольно, можно коллекционировать»
так что только за счет контент процесса больше тредов
с мультиком у меня сейчас 140 в основном процессе и 90 в контент
без мультика 100-120 с теми же вкладками
вероятно дополнительные потоки обрабатывают межпроцессное взаимодействие
кстати сча глянул, в основном процессе 150 потоков, в контент процессе 70 потоков
при том что открыто всего с десяток табов в основном с простым контентом
что они там делают — одному б-гу известно %(
хром жрет меньше фф? хром 32битны жрет стока же как 64битны?
вот на мной взгляд заслуживающий больше доверия бенч http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ там получается дето на 30% больше у 64бит
сомневаюсь что 64 битная версия даже 50% больше памяти использует, скорее 10-15%
впрочем весьма отдаленное
все равно что от например сервлетов вернутся назад к CGI
думаю дело в том что разработчики браузеров не в состоянии осилить многопоточное программирование (что не удивительно учитывая на чем они пишут) и потому вынуждены вернуться к разделенной памяти
хром допустим хвалится тем что если одна страница упадет то другие останутся, а вот сделать так чтобы не падало — им не по силам
фаерфокс с другой стороны даже не заморачивается на выделение по процессу на страницу, отдельный процесс занимается рендерингом всех страниц, и падают они как и раньше все вместе
единственное что улучшилось — теперь если какая-то страница начинает педалить то интерфейс браузер остается отзывчивым, но непонятно почему нельзя было точно так же вынести рендеринг страниц в отдельный поток а не процесс
а вот глючный GC как был пять лет назад так и остался https://bugzilla.mozilla.org/show_bug.cgi?id=646941