| 1.1, Вова (?), 10:01, 18/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Надо как-то затраты на синхронизацию потоков минимизировать, главная проблема в подобных задачах - ускорение переключения между потоками.
| | |
| 1.4, Dmitriy.trt (ok), 10:33, 18/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Это всё очень круто, но в Firefox до сих пор нет многопроцессной/многопоточной обработки вкладок, web-страницы даже от интерфейса не отделили. Запустите Gmail в одной вкладке и попробуйте в момент запуска поработать с другими, или просто по-водите по менюшкам Firefox в процессе загрузки - поймете о чем я. Именно поэтому многие называют Firefox тормозным, визуально он такой и есть. Для сравнения попробуйте то же самое в Chromium.
https://wiki.mozilla.org/Electrolysis/Firefox - вот над чем надо Mozilla трудиться.
| | |
| |
| 2.6, klalafuda (?), 10:39, 18/06/2011 [^] [^^] [^^^] [ответить]
| –5 +/– | |
> Это всё очень круто, но в Firefox до сих пор нет многопроцессной/многопоточной обработки вкладок, web-страницы даже от интерфейса не отделили. Запустите Gmail в одной вкладке и попробуйте в момент запуска поработать с другими, или просто по-водите по менюшкам Firefox в процессе загрузки - поймете о чем я. Именно поэтому многие называют Firefox тормозным, визуально он такой и есть. Для сравнения попробуйте то же самое в Chromium.
- Доктор, когда я делаю вот так (чешет левой пяткой правое ухо) у меня начинает болеть спина. Что мне делать?
- А вы не делайте!
| | |
| 2.14, Аноним (-), 11:41, 18/06/2011 [^] [^^] [^^^] [ответить]
| +6 +/– |
В Chromium то же самое. При загрузке нескольких тяжелых страниц в бекграунде подвисают даже уже загруженные страницы.
| | |
| |
| 3.18, Аноним (-), 14:10, 18/06/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> В Chromium то же самое. При загрузке нескольких тяжелых страниц в бекграунде подвисают даже уже загруженные страницы.
Нет, далеко не то же самое. Недавно наткнулся на ужасно идиотский сайт "Комсомольской Правды". Идиотское не содержание, а реализация... хотя и содержание не очень :-). Вот к примеру ссылка: http://nnov.kp.ru/daily/theme/1708/
Firefox 3.5 - открываем ссылки в виде вкладок, уже на третьей подвисание на 3-4 сек, после пятой открытой уже зависание серьезное. Когда отвиснет, открыть еще одну, снова зависнет.
Chromium 6.0 - открыл 17 вкладок, на 10-ой стало притормаживать, но на мои действия браузер продолжает реагировать. Мог бы открыть и больше, устал тыкаться.
Google Chrome 12 ведет себя чуть похуже, но он у меня увешан расширениями, думаю проблема в них.
При этом система на AMD Phenom 4X, 8Gb RAM. Наверное уже успело устареть, но все-таки не слабая машинка.
| | |
| |
| |
| 5.39, Аноним (39), 07:09, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > В опере вообще такой эффект не наблюдается у меня.
Попробовал в опере, действительно. Разве что она много памяти скушала, но в данном случае ведет себя даже лучше Хрома/Хромиума.
| | |
|
| |
| 5.27, 7134956 (ok), 19:43, 18/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Opera 10.50. Celeron 1700.
Десять вкладок без тормозов, но памяти скушали больше полгига :-(
| | |
| |
| 6.30, anonymous vulgaris (?), 00:01, 19/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
>Opera 10.50. Celeron 1700.
>Десять вкладок без тормозов, но памяти скушали больше полгига :-(
это просто наверно кэш указан большой, индексирование содержимого страниц не выключено, а так полгига это сотня вкладок, не меньше
| | |
|
| 5.40, Аноним (39), 07:17, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Firefox 4. Открыл 15 вкладок - никаких проблем.
Может быть 4-ая версия и стала работать лучше в этой ситуации. А как в других? Я уже не верю их заявлениям о том, что следующая версия быстрее предыдущей. Как уже написал ниже, использую еще с версии 0.8x, и много лет слышу заверения об улучшениях.
Почти как с KDE. Каждая версия быстрее и лучше, только мне KDE1 больше всех нравился. А в KDE4 сейчас вот kmix сожрал 1 гиг VIRT и 512 мб RES. Ну куда ему столько?! Или пора уходить с Debian stable на что-то более древнее :-)
| | |
| |
| 6.41, anonymous (??), 09:57, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Почти как с KDE. Каждая версия быстрее и лучше, только мне KDE1
> больше всех нравился. А в KDE4 сейчас вот kmix сожрал 1
> гиг VIRT и 512 мб RES. Ну куда ему столько?! Или
> пора уходить с Debian stable на что-то более древнее :-)
Кто же потребление памяти по VIRT меряет то?
| | |
| |
| 7.42, Аноним (39), 10:06, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Почти как с KDE. Каждая версия быстрее и лучше, только мне KDE1
>> больше всех нравился. А в KDE4 сейчас вот kmix сожрал 1
>> гиг VIRT и 512 мб RES. Ну куда ему столько?! Или
>> пора уходить с Debian stable на что-то более древнее :-)
> Кто же потребление памяти по VIRT меряет то?
А кто меряет? Я про RES, который в спокойном состоянии около 34-х Мб (вот как сейчас). А зачем микшеру понадобилось 512 Мб? Явно утечки. Этим кстати сабж грешит :-(
| | |
|
|
|
| 4.29, Аноним (-), 23:50, 18/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
Только что проверил. ФаерФокс 5ый, Хром 14ый.
Да, тормозит под фаерфоксом, но под хромом не лучше, если даже не хуже.
| | |
| 4.35, szh (ok), 10:14, 19/06/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Firefox 3.5, Chromium 6.0
Ого, где ты такие старинные версии откопал ?
| | |
| |
| 5.38, Аноним (-), 07:04, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Firefox 3.5, Chromium 6.0
> Ого, где ты такие старинные версии откопал ?
Debian stable :-)
| | |
| |
| 6.47, szh (ok), 19:53, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
В дебиан стэйбл никто не мешает поставить Firefox 5/Firefox 6 aurora и Chromium последний stable или beta или devel, при этом даже не снося старинные версии.
Стабильность нужна в системных компонентах и серверных программах, а не в отдельных GUI прогах. Если у вас раз в год браузер упадет - ничего с вами страшного не случится. Я пользуюсь beta каналами и у меня ничего не глючит.
| | |
|
|
| 4.46, pilat (ok), 12:02, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Как-раз пересел на Chrome с Firefox 3.5 именно из-за этой проблемы.
Но потом началось самое интересное: в Хроме, с каждой новой версией, отзывчивость уже закруженной вкладки во время загрузки чего-либо в соседней, стала все хуже и хуже, и уже к моменту решлиза Firefox 4, последный стал казаться ну просто мегу отзывчивым, по сравнению с поделием от гугла (причем и дома и на работе замечаю). Как-то вот так.
Вопрос к знатокам: а может быть такое, что девелоперам с определенного момента тупо надоело заморачиваться с изоляцией процессов при введении новых фич? Кто-нить следить за кодовой базой Chromium?
| | |
|
|
| 2.15, неанонимус (?), 13:21, 18/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
Кроме того, в фоксе все еще нет упреждающего чтения DNS и странички достаточно заметно по сравнению с хромиумом тормозят в начале обращения к ним. Только по этой причине я пользуюсь хромиум, хотя мне больше по душе фокс.
| | |
|
| 1.7, Anonus (?), 10:41, 18/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
И еще вопрос - который год обещают, что каждая вкладка станет использовать отдельный процесс... чего они добились с тех пор? Не знаю как в ведре, а в Linux этого явно нет.
| | |
| |
| 2.11, cmp (ok), 11:12, 18/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Точно. надо как в php-fpm, как и апач, как nginx, запускаем на старте мастер процесс и пяток дочерних, дабы не форкаться каждый раз, а с поддержкой запуска от имени указанного пользователя, chroot и cgroup рулить этим зоопарком будет просто и приятно
| | |
|
| 1.9, Аноним (-), 10:55, 18/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Это все хорошо, но меня скорость рендеринга устраивает. А когда они над отзывчивостью интерфейса будут работать? Пробовал все версии начиная с 0.8х, и каждая следующая работает все медленней и медленней. По моему, из браузеров серии Mozilla, самым удачным был Nescape 4.
Хорошо, хоть в Google постарались и сделали хром.
| | |
| |
| 2.17, Аноним (-), 14:00, 18/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Кстати, вышел 5-й FireFox
Релиз выйдет 21 июня, пока только файлы на ftp опубликовали и начали их распространение по зеркалам. До 21 июня эти файлы еще могут заменить, а релиз перенести.
| | |
|
| 1.20, Pilat (ok), 14:30, 18/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 не знаю как многопоточность, а у меня на скорость рендеринга влияет количество памяти, выделеное файрфоксу. Если больше 500-т мегабайт - скорость падает. Подозреваю, что лишние ядра ничего не изменят.
| | |
| 1.31, light (??), 00:48, 19/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
игры уже не заставляют покупать новое железо, будем развивать в этом же направлеини браузеры
скоро в минимальных требованиях запуска FF надо будет не менее 4 ядер
| | |
| 1.32, Андрей (??), 04:04, 19/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кстати, люблю открывать кучу вкладок (на "старом" P4 3.2). Ну, тормоза-тормозами, а вот заметил, что появляется какая-то регулярная дисковая активность (gnome-monitor аплет, каждые 10 сек). Наконец-то? методом проб и ошибок выяснил, что она появляется после открытия... opennet :) Интересно, нельзя ли как-то от этого избавиться? (кажись, аналогично с лором)
| | |
| 1.36, Вадим (??), 11:23, 19/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Когда уж гугл сделает что-то наподобие all-in-one sidebar в хроме? С удовольствием свалю от этого монстра
| | |
| 1.37, Аноним (-), 16:12, 19/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
докатились, теперь одного ядра нехватает для какогото текста с картинками....
ну может всетаки будет толк от 4-х моих много ядерных xeonчиков, а то первые 2-3 секунды после открытия новой вкладки тормоза... а то железо есть уже мнооого лет а пользоваться им еще не научились, может и flash 64 битный будет ? и кстати что radeon 7000 что radeon 2600xt толка от видюхи пока мало....
В случае WebGL обеспечение параллельности возможно за счет привлечения GPU. // -хде ??? невижу ...
| | |
| 1.43, Shura (??), 10:23, 20/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
[quote]В случае WebGL обеспечение параллельности возможно за счет привлечения GPU. // -хде ??? невижу ..[/quote]
тут наверное речь про WebCL, ибо WebGL такие задачи не решит.
| | |
| |
| 2.45, Аноним (-), 11:28, 20/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
> [quote]В случае WebGL обеспечение параллельности возможно за счет привлечения GPU. // -хде
> ??? невижу ..[/quote]
> тут наверное речь про WebCL, ибо WebGL такие задачи не решит.
Подразумевается то, что работа WebGL не грузит CPU, а параллельно расходует ресурсы GPU.
| | |
|
| 1.48, anonymous (??), 03:39, 21/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 я так понимаю, что гордон нашёл в эрланге Фундаментальный Недостаток и решил его переписать?
| | |
|
