"Memory usage in Firefox 3.1 Beta 3 (http://www.dedoimedo.com/computers/firefox-3-1-beta-memory.html)" - сравнение потребления памяти в Firefox 3.1 Beta 3 и Firefox 3.0.3, при выполнении одинаковой работы в обоих браузерах. В итоге, во всех экспериментах Firefox 3.1 Beta 3 потребляет процентов на 10 больше памяти, но при этом меньше загружает CPU и явно выигрывает в скорости обработки страниц и реакции на действия пользователя.URL: http://www.dedoimedo.com/computers/firefox-3-1-beta-memory.html
Новость: http://www.opennet.me/opennews/art.shtml?num=20960
И так браузеры, увы, мутанты что по cpu, что по памяти...
печально, но продолжаю их юзать
Гораздо лучше чем наоборот.
fennec зато жрёт мало памяти но медленно грузит странички хех прям зависть видим )
Довольно занятно, но неудивительно учитывая модифицированный жабаскриптовый движок + дополнительные навороты. Разумеется за это приходится платить, платить памятью:(
Вот одно я пока не пойму, вчера таки заствил себя поковыряться с xulrunner и поглядел как оно там изнутри, и сразу пришла в голову мысль - а почему таки альтеративных легковесных браузеров на его базе нет? Всмысле не мертворожденные проекты, типо епифани, в виде гуя+mozвиджет, а реальные проекты, которые бы даже вмешивались в начинку xulrunner и переписывали наиболее тормознутые компоненты. Вот это мне кажется наиболее перспективно, думается мне фонд мозиллы ещё долго будет не понимать важности легковесности. Писать кросплатформенные приложения на JS это круто конечно, но блин, есть желание например попользовать феннек на арм 400 мгц, и там оно шевелится не особо то:)
>например попользовать феннек на арм 400 мгц, и там оно
>шевелится не особо то:)Нокия успешно реализовала ваше желание :) и их системный браузер MicroB на основе Gecko вполне себе ничего.И памяти жрет умеренно.Но собственно XULного гуя и нету.За счет этого легкость и ... отсутствие темабельности и наворотов, ессно.За все приходится платить.
Рад бы согласится, если бы их MicroB не был бы тем самым эпифани подобным мертвяком. Может я недостаточно конкретно выразился выше, поэтому ещё раз попытаюсь.
Проблема мозиллы не в том, что у неё есть xulrunner с гуем на xml+js. Отказываясь от этого мы пишем собственный гуй и юзаем мозиловский геко как движок, но тогда мы, скажем так - не решаем проблему, а лиш убираем её самые такие явные фрагменты. Проблема же в том, что мозилловцы не слишком то пекутся о важности быстрого кода с малым потреблением памяти. Проблема в том, что XPCOM, будучи хорошей задумкой в смеси с С++ даёт какие-то не очень ахти результаты, которые почему-то отражаются на большем потреблении памяти и процессора нежели webkit. Тут конечно многие возразят: "мол мозилла поддерживает стандарты круто и умеет рендерить даже кашу из хрен знает как написанного html и поэтому медленно и тяжело". Но думаю японские дрели лучше русских не потому что русские много чего умеют, а потому что японцы научились чётко и планомерно устранять недостатки и развивать.
Так вот моё мнение таково, xulrunner, xpcom надо развивать, хорошо документируя каждый нюанс а не как сейчас. продвигать xulrunner как кросплатформенную девелоперскую платформу, расширить в xpcom поддержкой С, работать над поиском неэффективных решений в компонентах. И вот тогда уже даже xulrunner-based fennec будет работать прекрасно. Но я думаю всем понятно что сказать легко - а сделать сложнее:) Те же мелкий и мягкие в своё время взяли вполне себе вменяемую идею компонентов, реализовав аналог CORBA в виде COM. Но на практике оно оказалось хреново, что-то мне подсказывает, что проблема не в идее, а именно в реализации.
to ixrwsТаки пиши сам =)
Я думаю не ты один этого хочешь, а значит, если поискать вполне сможешь собрать команду, и вперед.
Мысль правильная, посмотрим найдётся ли достаточно времени или наоборот - не найдётся ли очередных "отмаз" у лени,почему не надо начинать этого:)