Думаю, что, если бы компы и каналы были вдвое шустрее, я бы работал процентов на 20 эффективнее. Очень много времени впустую тратится на то, что что-то нажал или запустил или сказал открыть и ждёшь отклика
( Read more... )
> Почему iTerm (обычная терминалка типа xterm)poigeDecember 10 2008, 18:56:24 UTC
> занимает 450M памяти?
Да брось! Во-1-х, iTerm это не «типа xterm» ни разу. xterm по сравнению с iTerm - крайне спартанская программа. Во-2-х, я думаю, ты путаешь - «450 M памяти» это далеко не оперативной. Оперативной - гораздо меньше. Аналогично и с
> Почему браузер, в котором открыты mrtg, looking glass, > bashorg и livejournal, сожрал 1.5G
- RSS и VSZ это очень разные вещи. А программы пухнут от того, что требований к ним всё больше. Попробуй поиграй в какой-нибудь Retal, и потом в Ил-2. Огромная разница.
Re: > Почему iTerm (обычная терминалка типа xterm)warunlockDecember 10 2008, 19:24:30 UTC
Боюсь, что программы в памяти пухнут не совсем от того. Берем например браузер. Смотрим размер. Открывем, а затем закрываем десяток страниц. И опять смотрим размер. И тихо прифигиваем. А на деле оказывается что просто кривые руки кодеров не удосужились дето нормально поосвобождать память. Как сейчас помню в универе мы дико возмущались по поводу диконавороченного полупроф драйверя для соунбластера который кто-то написал на вижуалбрсике и весил он АЖ целых 8 мб. А теперь таким размером тоже можно удивить.... ;)
> Боюсь, что программы в памяти пухнут не совсем от тогоpoigeDecember 10 2008, 19:37:11 UTC
Лучше бы вы боялись, что неправильно поняли смысл текста - оправданнее было бы.
> кривые руки кодеров не удосужились дето нормально поосвобождать память.
«Обожаю» невежд, которые уверены, что они знают. Про фрагментацию памяти в универе вам никто не рассказывал(?), судя по всему. И ошибки, конечно же, бывают, но многие программы пухнут именно из фрагментирования памяти (особенно это касается браузеров, в частности, Firefox). RTFM: http://en.wikipedia.org/wiki/Memory_fragmentation
P. S. И всё-таки, отмечу ещё раз, что смысл моего комментария вы просто-напросто не поняли.
Re: > Боюсь, что программы в памяти пухнут не совсем от тоwarunlockDecember 10 2008, 19:59:43 UTC
Дяденька, не ругайте меня. Я больше не буду. Я умные слова знаю. Например, сборка мусора. Хотя куда его приткнуть не знаю. Не подскажите? Хотя, наверное, это проблема не тех кто писал браузер. Но эндюзеру, по большому счету, глубоко .... кто и зачем сожрал его память. Результат удручает своими масштабами. Ну а если рассматривать "распухание" объемов программ на диске... Мне есть Вам шо сказать и на это тоже. Хотя вы, наверное, все и так лучше меня знаете. Можно я просто покиваю на самый первый пост в этом треде? И в заключение. Да я таки дурак и с этим не спорю. Но таки буйный.
Re: > Боюсь, что программы в памяти пухнут не совсем от тоnetchDecember 16 2008, 22:23:00 UTC
> Я умные слова знаю. Например, сборка мусора. Хотя куда его приткнуть не знаю.
Фигня в том, что к firefox оно не притыкается.;(( Потому что гарантированное освобождение памяти после сборки мусора возможно только в средах, которые сами управляют памятью и в состоянии найти ссылки и поменять их. А в C++ среде не положено менять указатели, поэтому может получаться, что один объект в пару байт на 4K странице - и её уже освободить нельзя.
Но у firefox, как и у прочих браузеров, похоже, таки утечки.
Re: > Боюсь, что программы в памяти пухнут не совсем от тоnetchDecember 16 2008, 22:29:09 UTC
Сколько лет прошло, а poige всё такой же авторитетный и неоспоримый. И по-прежнему считает, что есть два мнения - одно его, а другое неправильное. То, что ещё при Кнуте знали, что при среднем режиме использования динамической памяти и при всей фрагментации потери всего лишь 50% (и такой же КПД), ему невдомёк. И что речь не о режиме типа "один раз чего-то толстого посмотрели и память занята", а о том, что постоянно на каждой открытой и закрытой странице оно пухнет - а, значит, это уже не притянутая здесь за уши фрагментация, а реальные потери.
Так что в зеркало посмотрели бы насчёт невежд.
> P. S. И всё-таки, отмечу ещё раз, что смысл моего комментария вы просто-напросто не поняли.
Я вот тоже не думаю, что дело только в VSZ. От него не было бы заметных тормозов. Так что - не ерундите и не ерундимы будете.
> От него не было бы заметных тормозов.poigeDecember 17 2008, 04:45:17 UTC
Глупости это твоё кредо, я знаю. Если ты считаешь, что у gul-kiev было использовано 1,5 GiB именно RAM, то поинтересуйся, для начала об этом у него. Я в этом сомневаюсь, поскольку сам давно тему потребления памяти Firefox'ом мониторю. Да и не только Firefox'ом. VSZ Firefox'а у меня ща 946m, а RES - 281m. Разницу чуешь, своим стариканским носом?
Да и вообще, чё с тобой разговаривать - для тебя в любом споре и разговоре не истина цель, а раздувка свого унылого эго. Потому-то ты у меня и забанен. Bye-bye.
Спасибо, она подтверждает мои предыдущие комментарии. Больше в ней ничего интересного или полезного нет. Пойду греть работой свои старые мудацкие косточки, она интереснее тебя:)
Re: > Почему iTerm (обычная терминалка типа xterm)gul_kievDecember 10 2008, 22:21:37 UTC
я думаю, ты путаешь - «450 M памяти» это далеко не оперативной. Оперативной - гораздо меньше.
Я везде говорил про виртуальную память. Сколько из них оперативной, а сколько в свопе - это уж как операционка распорядится. Возможно, это запрошенная память, а не выделенная процессу (хотя этот вариант представляется мне странным). Насколько я знаю, в mac os x (как и в большинстве других os) память не precommited. Но даже если precommited, 450M - куда столько? Насчёт того, что iTerm намного круче, чем xterm - ну да, круче. Ну, может, килобайт на сотню кода. Плюс ещё на сотню килобайт всяких буферов (история и т.п.). Но откуда сотни мегабайт? Это на три порядка больше разумного объёма! Один порядок (целый порядок!) я готов списать на то, что я не понимаю нюансов, куда память совершенно необходимо деть. Но ещё два порядка засунуть всё равно некуда
( ... )
Re: > Почему iTerm (обычная терминалка типа xterm)netchDecember 16 2008, 22:25:13 UTC
С браузером просто не получится. Приходит CSS, приходит DHTML - и надо наворачивать 2-3 новых слоя абстракции. А это сразу потеря и памяти, и производительности. Ты же не хочешь, чтобы он умел показывать только в соответствии с HTML 2.0? Да, его достаточно чтобы показать, например, википедию:)
Ну и в остальных таки аналогично... правильно было бы сказать, что требования постоянно растут, и под них всё это пишется, но те возможности используют дай бог чтобы 1% пользователей.
Re: > Почему iTerm (обычная терминалка типа xterm)gul_kievDecember 17 2008, 13:36:59 UTC
Пожалуй, я бы хотел, чтобы браузер был маленьким, шустрым, и показывал только HTML 2.0 (с джаваскриптом, куками и прочим по мелочам). Я бы не хотел, чтобы в браузер были встроены flash player, google earth, skype, mail/news reader и т.п. Потому что, как показывает практика, они встроенные будут съедать память, даже если их не использовать. А перезапускать браузер, чтобы освободить память, получится примерно как ребутить комп.
> Но откуда сотни мегабайт?poigeDecember 17 2008, 05:09:46 UTC
:-) Я уже было забыл про эту тему, но тут пришёл netch-провокатор, так что и отвечаю на вопрос:
Оттуда - разделяемые библиотеки, и другие объекты (например шрифты). В Linux cd /proc/pid && less maps. Во FreeBSD и Solaris был pmap. Чего там в новомодной Mac OS X - не знаю. В общем, можешь мне на слово поверить - виной всему, как ни странно, разделение труда. :-) «Куча» тоже, ес-но, место занимает.
Впрочем, если соберёшь маленькую программку, со статически прилинкованным libc, получишь ещё более удручающую картину. Это всё не секрет, давно. Поэтому-то прежде, чем говорить о потреблении памяти, нужно смотреть карту распределения памяти процесса. Вот пример, в котором рассматривается не iTerm, но тоже не самая стройная «терминалка» - Konsole (из KDE4):
mapped: 344152 KB writable/private: 43340 KB shared: 22008 KB.
Re: > Но откуда сотни мегабайт?gul_kievDecember 17 2008, 11:36:46 UTC
Конечно, shared libraries, shared memory, c-o-w - это всё понятно, я не собираюсь суммировать virtual memory всех процессов. И понятно. что объяснить каждый конкретный случай сжирания памяти можно. Причём, несколькими разными способами. :)
Однако, "разделение труда" не объясняет тенденцию - почему я вынужден покупать всё более мощные компьютеры, чтобы иметь приемлемые тормоза на всё тех же незамысловатых задачах (ssh, mutt, icq, http). И сверхмощные на сегодняшний день компьютеры - чтобы не иметь тормозов на этих задачах. Такая же ситуация была и 5, и 10 лет назад, и будет ещё и через 5, и через 10 лет, когда компьютеры станут ещё в несколько раз мощнее.
Да брось! Во-1-х, iTerm это не «типа xterm» ни разу. xterm по сравнению с iTerm - крайне спартанская программа. Во-2-х, я думаю, ты путаешь - «450 M памяти» это далеко не оперативной. Оперативной - гораздо меньше. Аналогично и с
> Почему браузер, в котором открыты mrtg, looking glass,
> bashorg и livejournal, сожрал 1.5G
- RSS и VSZ это очень разные вещи. А программы пухнут от того, что требований к ним всё больше. Попробуй поиграй в какой-нибудь Retal, и потом в Ил-2. Огромная разница.
Reply
Берем например браузер. Смотрим размер. Открывем, а затем закрываем десяток страниц. И опять смотрим размер. И тихо прифигиваем.
А на деле оказывается что просто кривые руки кодеров не удосужились дето нормально поосвобождать память.
Как сейчас помню в универе мы дико возмущались по поводу диконавороченного полупроф драйверя для соунбластера который кто-то написал на вижуалбрсике и весил он АЖ целых 8 мб. А теперь таким размером тоже можно удивить.... ;)
Reply
> кривые руки кодеров не удосужились дето нормально поосвобождать память.
«Обожаю» невежд, которые уверены, что они знают. Про фрагментацию памяти в универе вам никто не рассказывал(?), судя по всему. И ошибки, конечно же, бывают, но многие программы пухнут именно из фрагментирования памяти (особенно это касается браузеров, в частности, Firefox). RTFM: http://en.wikipedia.org/wiki/Memory_fragmentation
P. S. И всё-таки, отмечу ещё раз, что смысл моего комментария вы просто-напросто не поняли.
Reply
Я умные слова знаю. Например, сборка мусора. Хотя куда его приткнуть не знаю.
Не подскажите?
Хотя, наверное, это проблема не тех кто писал браузер.
Но эндюзеру, по большому счету, глубоко .... кто и зачем сожрал его память.
Результат удручает своими масштабами.
Ну а если рассматривать "распухание" объемов программ на диске...
Мне есть Вам шо сказать и на это тоже. Хотя вы, наверное, все и так лучше меня знаете.
Можно я просто покиваю на самый первый пост в этом треде?
И в заключение. Да я таки дурак и с этим не спорю. Но таки буйный.
Reply
Фигня в том, что к firefox оно не притыкается.;(( Потому что гарантированное освобождение памяти после сборки мусора возможно только в средах, которые сами управляют памятью и в состоянии найти ссылки и поменять их. А в C++ среде не положено менять указатели, поэтому может получаться, что один объект в пару байт на 4K странице - и её уже освободить нельзя.
Но у firefox, как и у прочих браузеров, похоже, таки утечки.
Reply
Так что в зеркало посмотрели бы насчёт невежд.
> P. S. И всё-таки, отмечу ещё раз, что смысл моего комментария вы просто-напросто не поняли.
Я вот тоже не думаю, что дело только в VSZ. От него не было бы заметных тормозов. Так что - не ерундите и не ерундимы будете.
Reply
Reply
Заметь, я оценивал поведение собеседника, но не давал характеристики собственно собеседнику.
> Здоровья тебе.
"Не дождётесь" :)
Reply
Да и вообще, чё с тобой разговаривать - для тебя в любом споре и разговоре не истина цель, а раздувка свого унылого эго. Потому-то ты у меня и забанен. Bye-bye.
На тебе ссылку, на пенсии читать: http://blog.pavlov.net/2007/11/10/memory-fragmentation/
Reply
Так чего ж ты разговариваешь? Надеешься, что я начну разговор с того, что сделаю три раза "ку"? :)))
> Потому-то ты у меня и забанен.
Да уж, до того превентивный бан выставлял только Мицгол. У тебя хорошие учителя, ничего не скажешь.
> На тебе ссылку, на пенсии читать: http://blog.pavlov.net/2007/11/10/memory-fragmentation/
Спасибо, она подтверждает мои предыдущие комментарии. Больше в ней ничего интересного или полезного нет.
Пойду греть работой свои старые мудацкие косточки, она интереснее тебя:)
Reply
Я везде говорил про виртуальную память. Сколько из них оперативной, а сколько в свопе - это уж как операционка распорядится.
Возможно, это запрошенная память, а не выделенная процессу (хотя этот вариант представляется мне странным). Насколько я знаю, в mac os x (как и в большинстве других os) память не precommited. Но даже если precommited, 450M - куда столько?
Насчёт того, что iTerm намного круче, чем xterm - ну да, круче. Ну, может, килобайт на сотню кода. Плюс ещё на сотню килобайт всяких буферов (история и т.п.). Но откуда сотни мегабайт? Это на три порядка больше разумного объёма! Один порядок (целый порядок!) я готов списать на то, что я не понимаю нюансов, куда память совершенно необходимо деть. Но ещё два порядка засунуть всё равно некуда ( ... )
Reply
Ну и в остальных таки аналогично... правильно было бы сказать, что требования постоянно растут, и под них всё это пишется, но те возможности используют дай бог чтобы 1% пользователей.
Reply
Я бы не хотел, чтобы в браузер были встроены flash player, google earth, skype, mail/news reader и т.п. Потому что, как показывает практика, они встроенные будут съедать память, даже если их не использовать. А перезапускать браузер, чтобы освободить память, получится примерно как ребутить комп.
Reply
А вот дальше начинается, таки да, извращение.
Используй Konqueror и Opera, они намеренно сделаны чтобы быть полегче :))
Reply
Оттуда - разделяемые библиотеки, и другие объекты (например шрифты). В Linux cd /proc/pid && less maps. Во FreeBSD и Solaris был pmap. Чего там в новомодной Mac OS X - не знаю. В общем, можешь мне на слово поверить - виной всему, как ни странно, разделение труда. :-) «Куча» тоже, ес-но, место занимает.
Впрочем, если соберёшь маленькую программку, со статически прилинкованным libc, получишь ещё более удручающую картину. Это всё не секрет, давно. Поэтому-то прежде, чем говорить о потреблении памяти, нужно смотреть карту распределения памяти процесса. Вот пример, в котором рассматривается не iTerm, но тоже не самая стройная «терминалка» - Konsole (из KDE4):
mapped: 344152 KB writable/private: 43340 KB shared: 22008 KB.
Reply
И понятно. что объяснить каждый конкретный случай сжирания памяти можно. Причём, несколькими разными способами. :)
Однако, "разделение труда" не объясняет тенденцию - почему я вынужден покупать всё более мощные компьютеры, чтобы иметь приемлемые тормоза на всё тех же незамысловатых задачах (ssh, mutt, icq, http). И сверхмощные на сегодняшний день компьютеры - чтобы не иметь тормозов на этих задачах. Такая же ситуация была и 5, и 10 лет назад, и будет ещё и через 5, и через 10 лет, когда компьютеры станут ещё в несколько раз мощнее.
Reply
Leave a comment