about:memory ? в линухе ? О_О
ты тоже попутался сайтами?

> about:memory ? в линухе ? О_О

Открой новую вкладку в Огнелисе и введи адрес about:memory

Kubuntu 11.04 amd64, почему-то работает.

> 1 пеньке

64 Мб едо рам

5 фокс не по-детски тупит...

2011

Ой, ну надо же, и с чего бы это.

мануал в студию!

Ну в четвёртом фоксе с потреблением памяти не так печально, как в 3.6, который почему-то на моем железе тупил страшно, при том, что более ранние версии память щадили и работали быстро, особенно вторая версия хороша была. На версии 4.0.1 сейчас вот открыто 6 вкладок, включен флеш, фключена жава и 12 дополнений. Потребление памяти - около 200 метров. Быстродействие нормальное, тормозов не чувствуется. Но всё-таки 200 - многовато. Если 5-6 вкладок будут вмещаться в 120-150 метров (при всем включенном) в будущих версиях, это будет круто.

MemShrink — название технологии сжатия в Firefox, которая будет применена к отъедаемой памяти и ее утечкам.

> Он че внатуре у вас тут такой тролль глобальный, попутавшийся сайтами или стебется тонко?

Да просто безграмотное чмо.

> Не помогает. Открыто довольно много вкладок (обычно в районе 100), и если хотя бы одна из них начинает подвисать - виснет весь браузер и с ним невозможно работать.

У меня так же, часто и больше.

Да и на многих сайтах просто нужен жабаскрипт, т.к. на нём весь функционал основан. Эти-то сайты часто и вешают.

Нужен. Но у тебя какая-то выборка специфичная, попробуй еще сунуть в whitelist только те домены, без которых вообще не работает.

>Открой новую вкладку в Огнелисе и введи адрес about:memory

Memory Usage

Overview
Memory mapped:
Memory in use:
Other Information
Description   Value
No other information available.

Debian Squeeze. FF 3.6.17

а я сижу ,блин, через w3m и утечки памяти меня не волнуют.

А смысл? Да и какие утечки? Сколько не пользовался ff, утечки всегда были от плагинов - отключить кривые плагины. Мало памяти - настрой так чтобы не было большого расхода.

потестил у себя хромиум, мозиллу и реконк
на зажирание памяти. С течением времени
и при одинаковом количестве вкладок победил
реконк, что меня очень удивило...

> Debian Squeeze. FF 3.6.17

http://imageshack.us/f/29/screenzet.png/

ЧТЯДНТ? На 3.6 и на 4.* тоже всё работало.

Забавно. А есть ли браузер, который жрет меньше памяти?

> Подсказка: переопределите malloc/free и new/delete, или что вы там испольйзуете.

Мозилла давно использует собственный аллокатор и собственную заточенную именно под них реализацию GC.

Чем занята память можно посмотреть, набрав в адресной строке адрес about:memory. Понаставят всяких дико жрущих плагинов, а потом жалуются...

> Опера вообще идеал в использовании памяти

Хрен там. Когда в FF4 и в опере открываешь страницу опера жрет меньше. Но когда идешь по ссылкам дальше или возвращаешься назад FF4 освобождает занятую память, а опера жрет и жрет.

Кто-то где-то когда-то просил мануал ловите, и не орите ) http://www.linuxshare.ru/knowledge/browsers/q001.html

> Кстати, а умные небуржуи написали хоть какой-нибудь браузер? Хотя бы с утечками?

Нет. Зачем ещё одно говноподелие? Да и сосредоточения не всегда хватает (время-то есть). Хорошее приложение надо РОДИТЬ, а не бросаться сразу писать void main().

Хуле тормозишь, знаешь ведь как надо, а не делаешь!

Для хорошей приблуды надо сконцентрировать всё своё свободное время. Не всегда это получается, особенно после 30.

Когда код пишет дизайнер, а дизайном занимается программист, никакие языки тут не помогут.

Ваша правда. :) Но хорошие языки помогают хотя бы не делать совсем очевидных ляпов. После C# даже как-то смешно слышать о каких-то там утечках - люди кодят на Си, даже не представляя, насколько глупо и низкоуровнево они тратят время! Всё равно, что пересесть на перфокарты и ждять пол-дня компиляции.

Основная проблема не в том, что мы такие умные и ленивые :) (хотя и это правда), а в том, что те, у кого есть время и желание, тратят это время самым глупым образом, порождая очередной говноредактор или говноплеер. А всё из-за «наследия дедушек» - вермишели сипиписного кода. Была даже попытка сделать все системные утилиты на Перл! И людям это удалось - значит, не надо бояться отойти от Си - многие языки поддерживают линковку с посторонними модулями, так что без либ не останетесь.

> Да давно уже надо было всё на Джаве переписать. А лучше на Вижуал Бейсике.

Ничего смешного - куче ПРИКЛАДНЫХ программ вообще не упёрлись ваши смехотворные экономии байтов и микрогерцев. Зато экономия времени и избежание ляпов с памятью - огромные. Нужен язык как минимум с GC, чтобы не бегать с красными глазами, ставя очередные патчи.

Вот мой http://img225.imageshack.us/i/123yt.png/, работает правда недолго...

Ну я говорю по опыту:
Опера отлично живет на машине с 512RAM где система (с sshd, squid) жрет 150 мегабайт.
Лисофокс с легкостью за 350mb переваливает и лезет в своп.
Поэтому на слабых компах только опера, т.к Midori слишком любит сегфолты.

FireFox, Opera и т.п. работают медленней Chrome в Lin однозначно . В PCBSD Chromium побеждает все прочие браузеры . Google должен быть в Unix по умолчанию , но приходится доустанавливать видимо есть каккие-то договоренности с Mozilla .

> Основная проблема не в том, что мы такие умные и ленивые :) (хотя и это правда), а в том, что те, у кого есть время и желание, тратят это время самым глупым образом

Проблема в том, что кто ничего не делает, тот всегда знает как лучше.

А насчет устаревших технологий разработки ПО согласен (правда, это не реверанс в сторону C#). Средства разработки - скорость разработки - сложность ПО — имхо, вот тот треугольник, который обуславливает текущее состояние отрасли (e.g. «если вы выпустили хорошо протестированный продукт - вы опоздали с выходом на рынок»). Скорость разработки никто снижать не собирается (даже наоборот, пример тому новый цикл релизов лисы — почувствовали приближение хрома на графиках). Сложность просто так, без последствий, в «черные ящики» не распихаешь — все начинает тормозить, а клиенты уходить. Увеличение числа разработчиков имеет смысл лишь до определенного момента («девять женщин не смогут родить одного ребенка за месяц»). Да и интеллектуальный «потолок» разработчиков очевиден. Что-то у Гугла, имеющего возможности и нанимающего лучших специалистов планеты, не заметно особого прорыва в области быстрой разработки безбажного ПО.

Имхо, перспективы только в развитии средств разработки (возможно, в тесной интеграции с железом). Но вместо того чтобы признать кризисность сложившейся ситуации, многие во всем винят мифических быдлокодеров (которые всегда находятся где-то вовне говорящего о них субъекта). А Пайка, который один из немногих больше думает не о деньгах, а об отрасли в целом, называют старым маразматиком.

> Основная проблема не в том, что мы такие умные и ленивые :)

Ума не заметно (как-то та же mozilla не в России делается). А вот лени да... Её хоть отбавляй. Чуть выше тут пришлось рекомендовать «коньяку» (трёхзвёздному) таки скачать сырцы мозиллы на localhost. Он пытался смотреть код в веб-интерфейсе. Ничё так... Только тот код археологи нашли. На глиняных табличках он был изваян. ;)

После C# даже как-то смешно слышать о каких-то там утечках - люди кодят на Си, даже не представляя, насколько глупо и низкоуровнево они тратят время!

Нет. Мы не «кодим». Мы _пишем_ программы. И совсем неясно что тут можно (если о С говорить) напутать. Выделил память по malloc(), будь добр её освободить по free(). Руки перед едой моете? Во-во... Здесь примерно так же.

Второй вариант, поддерживаемый gcc, но не везде одинаково одобряемый (во FreeBSD этого например, не сильно любят) — выделить память в стеке через alloc(). Её даже освобождать не нужно, сама освободится по выходе из функции. Правда, есть ряд проблем, но если есть сомнения, то просто используется malloc()/free() и всё ровно.

Не всегда это получается, особенно после 30.

Видимо, Вы не пробовали. И да, «разработка» это уже не удел одиночек. Особенно, если что-то стоящее.

И людям это удалось - значит, не надо бояться отойти от Си - многие языки поддерживают линковку с посторонними модулями, так что без либ не останетесь.

И тут... брабанная дробь. Перл (равно как и большая часть библиотек до сей поры С (с чего бы это?)). Где Вы их возьмёте, если откажетесь от С?

Ну и да, а зачем менять «портируемый ассемблер» на какое-то говноподелие, позволяющее «не думать»? Если каждый дурак сможет написать программу, то нас ожидает просто шквал дурацкого софта (это уже сейчас заметно). Особенно по винде. Гораздо проще подсократить касту «программистов», переведя часть из них в касту «быдлокодеров». И посадив пейсать чё-нить до боли «оффисное». Где-нибудь в Индии. На крайняк, если будут столь тупы, что «ниасилят», можно будет заместо мартышек туристам показывать.

========================================

Ладно, лирика это всё. По сабжу. Боюсь, что проблема здесь не столько в самой мозиллке, сколько где-то на уровне libstdc++. Собственно, для чистоты эксперимента, сейчас целюсь пересобрать мозиллку со статическими либами. Доооолго ээээтттоооо... :(

Не...

> Нужен язык как минимум с GC, чтобы не бегать с красными глазами, ставя очередные патчи.

Есть три выхода.

Либо доработать существующие процессора под универсальную модель GC, да чтоб оно там само как-нибудь... А то в Java GC свой, в C# свой... Уже сделайте какой-нибудь один. Простой и понятный. И угомонитесь.

Либо таки сделать надо собой усилие и _действительно_ перестать писать говнокод.

Либо на хрен переквалифицироваться в какие-нибудь «оффис-менеджеры» и бросить этим вообще заниматься.

Здравствуйте, я возможно полный нуб. Просто ради интереса, задача браузера описывается конечным автоматом или нет?

Да. Не одним только. На самом деле, сам по себе протокол http (tcp/80) это так же описывается конечным автоматом. Браузер (выше уже писал) должен описывать как сами DOM-объекты, так и их поведение и преобразования, которые возможно производить.

В принципе, практически любую задачу, поставленную перед современной вычислительной техникой можно описать в терминах теории конечных автоматов. Это, как правило, здорово упрощает жизнь. В особенности, при поиске ошибок.

> kazehakase

Зачем нужна еще одна обёртка для webkit и gecko, которая ещё и тянет за собой gtk+?

1. Используем некоторое время Konq. 2. Возвращаемся на FF. 3. Понимаем, что у FF всё хорошо с памятью.

> Опера отлично живет на машине с 512RAM где система (с sshd, squid) жрет 150 мегабайт. Лисофокс с легкостью за 350mb переваливает и лезет в своп.

FF4? Какие аддоны установлены? Или это свежая установка на _чистом_ профиле?

>FF4?
Нет, 3.6 последний раз сравнивал, из аддонов adblock.
Комп использует пожилой человек для неспешного(ламерского) серфинга с 2-8 вкладками.

Вообще конечно же файрфокс тормознутое говно. Только вот аналогов vimperator/pentadactyl'а нет. Есть conkeror, но там чтобы привести его в порядок придется сорцы править, а у меня нет времени. Про uzbl surfraw и тп я вообще молчу. По сабжу — virt 1270mib(pmap), res 588mib. Одна вкладка, pentadactyl, флеш, stylish, scrapbook ещё там что-то по мелочи.

Да чёрт бы с рамой, да моём sempron 3100 здорово тормозит(по сравнению с оперой и conkeror'ом).

>1. Используем некоторое время Konq. 2. Возвращаемся на FF. 3. Понимаем, что у FF всё хорошо с памятью.

и с быстродействием, кстати, тоже

> полтора гига?! *шок*

http://www.linux.org.ru/jump-message.jsp?msgid=6372904&cid=6373216

;).

> Я сомневаюсь, что в FF именно утечки.

IMHO, это именно утечки - если убить процесс и перезапустить Firefox с восстановлением всех вкладок, объем занимаемой RAM снижается до 4-5 GB.

Где-то через недели 2-3 снова вырастает до 20 GB :(.

> Шесть гигов оперативки и никаких проблем.

Ну-ну. У меня 24 GB оперативки и проблемы есть - иногда комп не разблокировать, пока в консоли Firefox не убьешь :(.

> Firefox 4.0.1, при сорока вкладках ест ~500 метров. Ах да, быдлофлеша нет.

IMHO, flash уже давно в отдельный процесс вынесен и на потребление собственно firefox не влияет...

> Чем правильнее узнать реальное откушивание памяти в линухе того или иного процесса. Не виртуальной, а реальной оперативной.

Чем вывод top не устраивает? Самый простой способ:

ps aux | grep «имя процесса, или pid»

да у меня тоже в фф утечек нет.я просто через gprs вчера сидел:D

>Squeeze

FF 3.6.17

/0

>> попытка Mozilla устранить утечки памяти в Firefox
Наконец-то. Не прошло и 10 лет.

Сейчас очевидно, что это проблема настолько велика, что усилий одного человека недостаточно.

Сейчас очевидно, что фиксить это надо было с самого начала.

>> Пожалели рамы на хорошую программу.
Кластер детектед.

Странно, у меня память не жрёт, 12 вкладок (из них 4 с Ютубом), выделение памяти ~280 - 290 мегабайт.

И тебя вылечат.

Nightly 7.0a1 x86_64

Открыто 52 вкладки

top - 10:53:41 up 2:30, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 299 total, 1 running, 297 sleeping, 0 stopped, 1 zombie CPU0 : 13.2%us, 1.6%sy, 0.0%ni, 84.9%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st

CPU1 : 6.8%us, 1.0%sy, 0.0%ni, 92.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

CPU2 : 7.5%us, 1.3%sy, 0.0%ni, 91.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

CPU3 : 9.6%us, 0.3%sy, 0.0%ni, 90.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 4060844K total, 2191232K used, 1869612K free, 40064K buffers

Swap: 8123432K total, 0K used, 8123432K free, 750148K cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9532 vic 20 0 671M 95M 23M S 7.6 2.4 14:50.50 plugin-containe

9086 vic 20 0 1317M 715M 30M S 4.6 18.0 7:17.75 firefox-bin

9541 vic 20 0 671M 95M 23M S 3.0 2.4 3:00.13 plugin-containe

9543 vic 20 0 671M 95M 23M S 3.0 2.4 3:03.48 plugin-containe

9540 vic 20 0 671M 95M 23M S 2.7 2.4 3:04.16 plugin-containe

9542 vic 20 0 671M 95M 23M S 2.7 2.4 2:59.45 plugin-containe

9538 vic 20 0 671M 95M 23M S 2.3 2.4 3:01.57 plugin-containe

9539 vic 20 0 671M 95M 23M S 2.3 2.4 2:58.76 plugin-containe

9537 vic 20 0 671M 95M 23M S 2.0 2.4 2:27.13 plugin-containe

9487 vic 20 0 1317M 715M 30M S 0.3 18.0 0:32.14 firefox-bin

кстати about:memory

677.59 MB (100.0%) — explicit

├──365.91 MB (54.00%) — heap-unclassified

├──174.03 MB (25.68%) — js

top - 17:05:42 up 33 days,  1:44, 16 users,  load average: 0.00, 0.03, 0.00
Tasks: 518 total,   1 running, 517 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.0%us,  2.0%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 22.5%us,  0.3%sy,  0.0%ni, 77.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.3%us,  1.3%sy,  0.0%ni, 98.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  5.3%us,  1.0%sy,  0.0%ni, 93.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  1.0%us,  2.0%sy,  0.0%ni, 97.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.7%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.3%us,  0.7%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu9  :  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.7%us,  0.7%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  1.0%us,  1.3%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.3%us,  1.0%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.7%us,  0.7%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:  24800244k total, 24679068k used,   121176k free,   359512k buffers
Swap:  2104472k total,  2103476k used,      996k free,  2226468k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 2430 serge     20   0 20.7g  17g  26m S   33 71.9   2871:43 firefox            
 2477 serge     20   0  664m  73m  14m S    7  0.3   1221:32 plugin-container 

Firefox 4.0.1.

Кнопочку с цеферкой «1» вы как бы случайно нажали?

Valgrind не работает с firefox. Пруф:

startapp@ubuntu:~$ valgrind firefox
==2810== Memcheck, a memory error detector
==2810== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2810== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==2810== Command: /usr/bin/firefox
==2810== 
startapp@ubuntu:~$

$ file /usr/bin/firefox

причем тут планка памяти? в любом случае будет мало, оптимизировать нужно программу на возврат памяти!