Не так. Основная фишка — каждый сайт в своём ПРОЦЕССЕ. Многоядерные процессоры с тем же успехом работают и с отдельными потоками (threads). Но изоляция сайтов на уровне OS должна здорово повысить безопасность и устойчивость. Но, что бы они не говорили в комиксе, на винде это ухудшит производительность. На MacOSX и *IX не должно, по идее.
PS: Вот в юниксовом шелле, например, каждая команда запускает отдельный процесс... разве "неоптимальныая производительность" такой связки заметна на глаз ?
Не нужен Exec. Держим процесс "пустого" браузера, при необходимости командуем ему fork() из процесса-менеджера (который объединяет в себе все табы) — и всё. exec не нужен. Другое дело, что именно на винде это будет таки CreateProcess(), который недёшев, в отличие от fork().
Хороший метод вообще-то. Зато броузер производительней. Но таб тормозит только изредка, и один раз, а броузер производительней всегда.
Почему-то никто не упоминает, что их устраивает производительность броузера. Хотя я не припоминаю случая, чтобы мне эта производительность броузера хоть когда-то была важна. Ну и про утечки памяти всё справедливо. Правда и один таб может нацедить памяти немало. :)
Хотя я не припоминаю случая, чтобы мне эта производительность броузера хоть когда-то была важна. Каждое открытие интерфейса gmail я припоминаю об этом.
А я нет. Хотя компы бывали и слабоватые. И честно сказать не в курсе -- неужто в гмейле такая уж сложная страничка? Вот не большая, а именно сложная (мы ж не толщину интернет-канала обсуждаем)?
А я нет. Хотя компы бывали и слабоватые. У меня FireFox подвисает до (not responding) на 1-2 минуты. Всех екстеншенов — 6 штук, самых обычных. Firebug для доменов гугла запрещён.
неужто в гмейле такая уж сложная страничка? Практически полноценный GUI, с редактором, списком сообщений, всё это асинхронно подсасывается в фоне, etc? Там килобайт 200 сжатого джаваскрипта вообще-то. Это очень много.
"много кода" и "прожорливый код" -- всё-таки две большие разницы.
(У меня экстеншинов чуть больше -- 10.)
На 1-2 минуты у меня бывает подвисают сааамые разные сайты. Тот же ЖЖ например. Но не постоянно. Гмейл иногда задумывается, но частенько загружается моментально. Неужто код его странички иногда резко упрощается? Может дело всё-таки в загрузке сервера, в интернет-канале, и т.д.? Впрочем, в пользовании мой гмейл вполне... как бы это... "отзывчив"? Достаточно шустр для использования, короче.
ну это вам не везёт с работой. рискну предположить, что большинство сёрферов всё-таки редко отлаживают свои сайты и т.д. Да и вам никто не мешает запускать тестовую страничку в отдельном броузер-процессе.
> спасибо, вы мне открыли глаза на то с чем мне везёт
Взаимно. :-Р
> и мне кажется что это хорошая попытка +1
Только вот сомневаюсь, что при оценке этой попытки "производительность броузера" будет иметь для меня вес. Вполне допуская, что это имеет вес для существенной прослойки сёрферов, и что это станет причиной использования Оперы и пр.. Но не думаю, что для большинства.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Вторая фишка — новый движок JavaScript с JIT.
no subject
no subject
Там, в общем, что поток, что процесс — разница невелика.
no subject
PS: Вот в юниксовом шелле, например, каждая команда запускает отдельный процесс... разве "неоптимальныая производительность" такой связки заметна на глаз ?
no subject
Другое дело, что именно на винде это будет таки CreateProcess(), который недёшев, в отличие от fork().
no subject
no subject
no subject
no subject
no subject
no subject
процессоры-то в любом случае прокачаются, куда они денутся.
если уж утилизировать их мозности, так хотя бы с пользой и удобством.
no subject
Зато броузер производительней.
Но таб тормозит только изредка, и один раз, а броузер производительней всегда.
Почему-то никто не упоминает, что их устраивает производительность броузера. Хотя я не припоминаю случая, чтобы мне эта производительность броузера хоть когда-то была важна.
Ну и про утечки памяти всё справедливо. Правда и один таб может нацедить памяти немало. :)
no subject
Каждое открытие интерфейса gmail я припоминаю об этом.
no subject
И честно сказать не в курсе -- неужто в гмейле такая уж сложная страничка? Вот не большая, а именно сложная (мы ж не толщину интернет-канала обсуждаем)?
Впрочем, см.п.1.
no subject
У меня FireFox подвисает до (not responding) на 1-2 минуты. Всех екстеншенов — 6 штук, самых обычных. Firebug для доменов гугла запрещён.
неужто в гмейле такая уж сложная страничка?
Практически полноценный GUI, с редактором, списком сообщений, всё это асинхронно подсасывается в фоне, etc? Там килобайт 200 сжатого джаваскрипта вообще-то. Это очень много.
no subject
(У меня экстеншинов чуть больше -- 10.)
На 1-2 минуты у меня бывает подвисают сааамые разные сайты. Тот же ЖЖ например. Но не постоянно. Гмейл иногда задумывается, но частенько загружается моментально. Неужто код его странички иногда резко упрощается? Может дело всё-таки в загрузке сервера, в интернет-канале, и т.д.? Впрочем, в пользовании мой гмейл вполне... как бы это... "отзывчив"? Достаточно шустр для использования, короче.
no subject
я часто отлаживаю свои сайты, и отсматриваю чужие, в том числе бета-версии.
и мне очень нужно знать какой именно из табов гадит.
no subject
рискну предположить, что большинство сёрферов всё-таки редко отлаживают свои сайты и т.д.
Да и вам никто не мешает запускать тестовую страничку в отдельном броузер-процессе.
no subject
ну а если серьёзно - веб-приложения усложняются, и браузер как платформа начинает ограничивать разработчиков, а вслед за ними и пользователей.
и мне кажется что это хорошая попытка что-то радикально изменить в текущей ситуации.
no subject
Взаимно. :-Р
> и мне кажется что это хорошая попытка
+1
Только вот сомневаюсь, что при оценке этой попытки "производительность броузера" будет иметь для меня вес. Вполне допуская, что это имеет вес для существенной прослойки сёрферов, и что это станет причиной использования Оперы и пр.. Но не думаю, что для большинства.
no subject
шустренький )