Здравствуйте, _Artem_, Вы писали:
_A_>Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
Чтото маловато... Как добились?
[RSDN@Home][1.2.0][alpha][648]
[Одно и то же слово и совет Hа пользу мудрецу, глупцу во вред. [аль-Хусри]]
Здравствуйте, Sinclair, Вы писали:
S>Конечно, мои знания ограничены.
Они у всех ограничены. Все знать нельзя — не DOS времена.
>Но тебе же незнание основ устройства дотнета не помешало критиковать его?
Как раз по устройству его я в общем себе более или менее представление имею — ну на уровне Рихтера хотя бы. Вот с библиотеками классов — это да, тут я высказываться в духе "это надо делать так или это нельзя делать" — поостерегусь
S>У меня нет под рукой Соломона-Руссиновича.
Настоятельно советую купить. Я серьезно говорю. У меня такое впечатление, что ты (и не только ты, скорее вы все) то ли не хотите, то ли времени нет, то ли еще что-то — но не знаете и не понимаете базовых механизмов функционирования ОС. Отсюда порой анекдотические заявления (и не только твое). А когда человек такие заявления делает, то доверие к тому, что он и по другим поводам говорит , резко падает — он же базу не знает.
S>Возможно, я что-то неверно понимаю. Но ты не мог бы мне пояснить, как именно Working Set процесса влияет на остальные процессы? Вот у меня типичное количество свободной физической памяти ~ 500 mb. Это означает, что отожранные янусом мегабайты никому не жмут. Я также заметил, что янус отжирает не фиксированное количество памяти. Когда у меня было 525 метров — он тратил 30 метров. Сейчас — 112.
Ничего удивительного
if(lowMemory)
VirtualAlloc (еще)
else
// как-нибудь обойдемся тем, что есть
И если в коде Януса такого явно и нет, то это не значит, что такого нет в .Net Framework или в исполняющей системе.
>Process Explorer при этом показывает 94.6 MB Private Bytes. Он же показывает 45 мегабайт во всех хипах дотнета. (Это все три поколения + Large Objects Heap). При этом Reserved = 92 Mb. То есть на всякий случай дотнет держит полсотни метров памяти про запас. Что-то мне подсказывает, что эти байты можно при нужде легко отдать. S>Вот я сминимайзил януса — и его working set стал 1.5 Мb. Примерно за полсекунды. То есть когда у меня таки кончатся эти 500 метров свободной памяти (что означает, что я запустил какой-то еще фотошоп), янус подвинется и отдаст.
Попробую объяснить.
Private Bytes — это не так интересно. Равно как и Commited Bytes (включает в себя еще и не-private). Это объем вирт. памяти, который процесс коммитировал. Грубо говоря, это объем тех адресов, по которым можно обращаться без того, чтобы схлопотать AV.
Мне ничего не стоит сделать Commited Bytes (в Task Manager называется VM Size) для своей програмы большим, чем размер RAM. При этом часть будет выделена в RAM, часть в файлах (свопе, MMF)
А вот Working Set — это совсем другое дело. Это те страницы, которые сейчас в RAM. Это то, что твоя программа сейчас забрала себе.
Все процессы начинают работу с фиксированного Working Set (значений под руками нет). Далее они могут запрашивать все больше и больше памяти, VM Size будет у них расти (только они сами могут его потом уменьшить, освободив память) а вот будет ли при этом увеличиваться
Working Set — зависит от ситуации в машине. Если памяти RAM свободной много, то будет. Более того, система может даже дать больше, чем максимум (см. SetProcessWorkingSetSize). Если же памяти мало, то система будет вытеснять страницы, а не давать новые.
Теперь о минимизации. Разумеется, система отдает предпочтение активному приложению. И вот его минимизировали. Поскольку ты явно заявил, что не будешь с ним работать сейчас (правда это или нет — другой вопрос), то система усекает его Working Set , отнимая у него страницы.
А их куда девать ? Зависит от того, попадут ли они в список простаивающих или модифицированных. Если это страницы кода, то в первый (скорее всего), если данных — во второй (опять же скорее всего). Простаивающие страницы — кандидаты на выделение их другому процессу (после обнуления), модифицированные надо прежде того записать на диск , а потом уж давать другим.
Так чот уменьшить Working Set можно мгновенно практически — просто объявить эти страницы более не принадлежащими процессу, и все. Никакой записи на диск при этом вообще не произойдет.
Записью же на диск занимается поток отложенной записи. Ему до минимизации, макисмизации, выделения памяти каким-то процессом или освобождения им памяти напрямую дела нет. Он просто ждет на двух событиях. Одно будет установлено, когда количество модифицированных страниц превысит некий максимум, а другое — когда количество свободных страниц станет меньше некоторого минимума.
Теперь сам можешь понять, что происходит. Минимизировали приложение. Уменьшился резко Working Set. А дальше что будет — зависит от a) много ли RAM и b) насколько агрессивно новый процесс (с которым теперь начали работать) запрашивает память и как давно с ним не работали.
Если RAM много, а преемник не агрессивный, то отложенную запись будут откладывать . Некуда спешить — в системе тихо и мирно, всем памяти хватает.
Но если RAM мало, или преемник агрессивный, или с ним просто давно не работали (а для давно минимизированных процессов ОС может довести его Working Set до нуля), то начинается вот что. Преемник хочет памяти (или явно сейчас запрашивает, или, если с ним давно не работали, то он сейчас вернулся и просит вернуть ему Working Set . Срабатывает событие "количество свободных страниц станет меньше некоторого минимума". Начинается запись модифицированных страниц. Одновременно идет чтение страниц преемника (а куда денешься!). В итоге тормоза.
У меня на машине этот эффект проявляется, к примеру на Mozilla. Она у меня запущена всегда и я с ней почти не работаю, могу час-два к ней не обращаться. Если запустить некий процесс, активно отъедающий память, а потом переключиться на Мозиллу — тормоза очень заметны.
Так что чудес не бывает. Суммируя, могу сказать- если процесс захватил 60 Мб Working Set и эти данные не R/O, то их записывать на диск будут (разве что процесс убьют, тогда, мб, и не будут). Но, конечно, не немедленно, а когда потребуется. И если таких процессов много (а минимизация, как сам понимаешь, отнюдь не гарантирует, что процесс не будет ничего делать, это лишь в большинстве случаев так), то свопинг будет хороший. Но размазанный по времени, так что ощутит юзер тормоза или нет — от многих факторов зависит.
Поэтому , кстати, ASP.NET пользуется большой популярностью, а WinForms — нет. Для ASP.NET процесс-то, по существу, один — aspnet_wp.exe. Даже если там пять сайтов крутится и пользователей из Интернета тысяча. А вот если все приложения на рабочей станции перевести на .Net — будет тихий ужас. Если простенький пример Влада ухитрился иметь 60 Мб Working Set (хоть убей, не понимаю, как такого можно добиться! Если бы от меня потребовали такое на Win32 написать — отказался бы, не знаю, как это можно сделать — то при десятке таких приложений будет примерно то, как работа Windows 95 на 4 Мб. Не пробовал ? MS тогда заявила, что будет работать (3.1 прекрасно работала). Я и попробовал
PD>>Антон, честное слово — почитай. Тебе самому стыдно будет читать, что ты здесь написал. PD>>Вообще меня удивляет в тебе одно. Ты прекрасно разбираешься во многом. Но зачем ты делаешь заявления в том, в чем ты явно не разбираешься — это я понять не могу. S>Я не делаю заявлений. Я не понимаю, почему начинаются сказки про прожорливость приложений, которую так трудно заметить. Я не вполе понимаю все это многообразие цифр, которые показывают различные перформанс тулы. Я вижу, что весь этот Working Set — это фикция, поскольку легким манием руки он прыгает с 400 до 2, а потом до 30М.
Надеюсь, теперь понял, что это не фикция ? И опять-таки, твое поведение меня удивляет. Ну не понимаешь, ладно, ничего страшного, поищи информацию, почитай, поймешь же без труда, не так уж это сложно. Но зачем же фикцией называть, если ты не понимаешь ? Лучше сначала разобраться, а потом и не захочется фикцией называть.
И последнее. ИМХО у тебя сложилось впечатление, что я противник .Net. Вовсе нет. В целом я ее существование только приветствую, и отдаю ей должное. Хорошая система. Но не надо ее возможности преувеличивать. Поэтому я смотрю на вещи трезво. В чем-то она хороша, в чем-то нет. В чем-то классический С++ прекрасен, где-то его лучше и не пытаться применять. А вот для вас, похоже, нет бога, кроме .Net и бог един, посему остальным — анафема и костер!
Ну и коль уж о боге речь зашла, закончу фразой из писания
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А чего вы хотите ?
Чтобы люди не не фильтровали то что им говорят.
Уже 100 раз было сказано, что ЖЦ по умолчанию отедает несколько мегабайт на машинах где есть много памяти (10 это вполне нормальная цифра).
Если на машине будет нехватать памяти, то апетиты уменьшатся.
Что касается конкретного примера, то уверен, что там не по одной маленькой строчки на строку таблицы использовано было. И таблица была не ListView, а что-то сильно по навароченее. Так что сравнивать тут нечего.
Ради хохмы вот статистика на моей машине (содержащей 2 Гб памяти):
Что? Mem Usage VM Size
Пустое ВыньФормс-приложение 11 432 19 656
ВыньФормс-приложение с пустым DataGridView 11 432 19 656
ВыньФормс-приложение с DataGridView
заполненным 10 000 строк (с одной колонкой) 16 764 17 856
ВыньФормс-приложение с DataGridView
заполненным 10 000 строк (с одной колонкой)
после изнурительного скролинга по всем
строкам 60 496 61 032
Тоже что и придыдущий, но перед просмотром
обема занимаемой памяти произведена
минимизация и востановление окна 8 100 61 032
ListView заполненный 10 000 строк
(табличный режим, одна колонка) 14 188 17 340
Тоже самое после скролинка 15 480 18 400
Тоже самое после минимизации и
востановления окна 5 090 16 600
В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти, то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта. Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>Чтобы было прикольнее пишу это сообщение с 40 параллельно запущенными тестами в каждом из который торчит тот самый не экономный грид с 10 000 записей каждый. параллельно рабатают еще около 40 процессов среди которых Судтия, Янус
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали: A>Супер, Павел, просто супер. Но до здравого смысла этих людей пробиться сложно. Упорные они. Я пытался. Мало что выходит:
Вообще, почитав посты этой темы, у меня сложилось впечатление о некоем противостоянии двух лагерей. В обоих лагерях участники имеют нешуточное представление как об внутренних механизмах ОС так и о языках прогр. Оба лагеря знают, что раньше все прогр.-мы сначала скромно перекусывали потом стали аккуратно есть а теперь просто жрут. Также все представляют (покрайней мере, я — в общих чертах) как наша любимая хрюша все это дело кормит, тобишь как распределяет рес. памяти. Кстати, может тут будут и смеяцца, но мне лично этот принцип распределения напоминает работу нашего мозга, так что если ктото досих пор недолюбливает работоспособность поделок от дяди билли, то эээ... интересно, как вы сами ссобой уживаетесь?
Ладно. Едем дальше..
В итоге все в курсе всего. Но тут возник вопрос. И началось... Одна умная голова заявила, что это, мол, хрюша пашутила и все насамом деле наместе — вот вам на суд рез-ты исследований. Другая голова поглядела и недоуменно возразила, что, мол, ОС шутить отродясь неумела и со времен рождества христова в соответсвующей божественной манере она отдавала всем кто нипопросит и столько, сколько никто не унесет. А чтО там несчатная приблуда будет делать дальше с сиими дарами операционным это ее проблеммы. Все подкреплено фактами и Все с этим согласны. Ладно хоть более темная и неграмотная часть жителей средиземья и севера, в рез-те этой перепалки стала лучше понимать хитрую ситему накормления семью хлебами и приобрела не менее хитрое знание о захапывании и делении. Дааа.. однозначно любимыми мат. операциями человека, сотворившего GC были операции отнимания и деления. Но мир никак нибрал стороны и идет пережовывание как разных, так и одних и техже фактов, цитат и тд., причем, хорошо известных обоим сторонам. И я никак немог ухватить вчем именно расходяцца ваши взгляды. Со стороны диалог сторон напоминает одну современную басню о покупке гопником чего-то там у глуховатой бабушки, торгующей картошкой —
"Да ты, бабка глухааяя!". "Чтоо?! Ааа! Да, сынок! Есть и гнилая!"
Но вопреки присутствию щедрого директора и жадного приложения в одной клетке, долгожданный всеми крах от их сожительства ненаступает. Сисадмины насторожены — Хрюша им в стук-листе рисует факт пропажи 40мб. Баггер-дамп-разведка подтверждает. "Блин!" — думают они, если все кодеры переберуцца на шарп и буду там такие жирные плюшки клепать, то блин, унас такой жор начнецца, что все демоны попадают. Так вам глядишь и самим писАть придецца.
А кодеры врасслабухе — "Пацаны в редмонде нашинские, тапочки курят такие же как и мы". А дядя Билии ваще наш старший брат. Блин, чесслово, мой старший брат так обомне не заботицца как дядя Билли. Меня например ваабще перестало интересовать, скролько шарп-проги стали жрать.
После прихода GC истиной так и остаецца простая зависимость производительности программы от кол-ва лишневыделенной оперативки. Так что мы свою шарп-глюкалу полностью понимаем и знаем зачем ей столько и куда. И даже недумайте наши законные два гектара маны отнимать. Посидите с наше на смещениях да на параграфах и потом машите выдержками и цитатами. А этому бедному, замордованному злобными сисадминами Артему и его команде могу сказать, что можете смело идти, переходить, садицца и радовацца. А если там какой нить больно великий админ начнет плакать, мол, из-за вашего творения у нас порнодум-10 притармаживает, сотвори ему теже 10 тыс. обращений на серв с логина, без отсоединенного кэша. Вместе с пулом пусть там накроюцца. Скажете, "у вас кабель узкий". Ато блин дайте нам стабильность, скорость, безопасность и чтоб само все набиралось, а сама БД и СУБД помещались на дискетку (вместе с сотней ихних любимых порнотелок).
Непонятно зачем вааще мелкие расказали о GC. Надо было им лишь отметить, что памяти в этом языке, даже как понятия, нету и спрашиват об этом всеравно что спрашивать об НЛО — откуда они приходят и куда улетают. Все чем занимаюцца в шарпе это манипулируют как готовыми обжектамим так и своими. А на ныряния во внутренности GC со стороны штаба админов можно сказать только то, что занятие это для них напрасное и бессмысленное если они еще не пытались заняцца проблемой автоуказателей. В процессе решения этой проблеммы вопрос "куда все пропало?" раскрываецца сам собой на базовом уровне точно также как и перед создателем первого парового двигателя открылся бы секрет движения нового баяна. А вы как бугалтера-колхозники: "По накладной под капотом должно быть сорок лошадей. Вытаскивайте их оттуда по одной — унас инвентаризация." И что вам на это ответить? Только одно — ложки несуществует.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Однозначно требуется специалист, способный отучить тебя от хамства. Боюсь только, что это никому не под силу.
Предлагаешь обсудить личности друг друга? ОК.
Понимаеш ли какое дело, Павел... У тебя натуральная психологическая проблема. Ну, не привык ты к сегодняшним объемам памяти. Все досовские времена вспоминаешь. От того тебе и мерешится хамство когда тебе указывают на твою проблему.
Ну, да это не главная проблема. О главной я уже говорил, и ты несомненно думаешь, что и это хамство. Если хочешь, обсудим это еще раз... Но наверно все же не стоит обсуждать друг-друга.
Так что оставь другим самим решать, кто прав, кто не прав, кто хам, а кто бездарь. ОК?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
есть такая крылатая фраза — горе от ума Чем глубже мы погружаемся в какую-либо область и чем более ясны логические цепочки — тем тяжелее нам представить что-либо, что не вписывается в наши логические выводы в этой области. Об этом нужно всегда помнить — такова специфика нашего мозга — обладая глубокими знаниями о чем-либо — наш мозг отбрасывает все, что идет вразрез с этими знаниями Птицы тоже не должны летать, т.к. они тяжелее воздуха. И в теорию относительности я не верю (уж больно какая-то она сухая), несмотря на то, что логически она очень даже выстроена
Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.
Вот например жизненная ситуация — послали тебя в командировку, поселили тебя одного в пятиместный номер. Что ты делаешь? правильно, распологаешься на "широкую руку" — все свои вещи по всему номеру, пиво поближе к себе, носки поставишь в дальний угол Тебе так удобно? да. Но это не значит что ты уже не сможешь существовать в более маленьком пространстве. Завтра приедут остальные 4 твоих товарища — и ты в течении 5 минут всё свое барахло стягиваешь к своей койке, ну носки возможно прийдется даже постирать Тебе удобно так? конечно, одному было вольготнее, но и в таких условиях можно вполне сносно существовать. А не приехали бы сослуживцы — может, ты бы носки так бы в угол и ставил бы и на стирку времени не потратил. Да, есть тут момент — вещи нужно к себе сгребать в случае резкого появления сожителей. Ну такова специфика. А зато если бы не приехали — ты бы более "эффективно" жил бы, нежели если бы сразу занял только свой уголок.
Так и .NET . Вообще-то ему нужно чтобы было много памяти на машине — чтобы было где развернуться, а потом можно потихоньку уменьшать свое жизненное пространство...
Здравствуйте, parapet, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.
P>а может и не круглая. А если и круглая — то для некоторых задач мы вполне можем ее рассматривать как плоскую. И результаты будут достаточно точны.
Люди, вас обманули! Земля вовсе не круглая! Круглым может быть только что-то двумерное. Широко известно, что Земля имеет форму Земли. Так и называется: "геоид".
Существует огромное количество задач, для которых и шарообразная форма, и эллипсоидальная — слишком неточные приближения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
По ходу этой дискуссии видно, что не все представляют, что находится в памяти .NET процессов. Из этого проистекают всякие разные домыслы и предположения, которые по большей части не имеют отношения к действительности. Поэтому я попытаюсь очень кратко показать, как посмотреть в память .NET процесса и определить, зачем она используется и по возможности, как её можно уменьшить.
Для примера я возьму уже обсуждавшееся приложение, в котором создаётся grid и заполняется 10000 строками данных. В моём случае я его ещё дополнил кнопкой "GC.Collect", чтобы вызывать сборку мусора, когда необходимо для тестовых целей. Визуально это выглядит вот так:
Код для приложения элементарен и выглядит так:
for (int i = 0; i < 10000; ++i)
{
string [] rows = new string[3];
rows[0] = i.ToString();
rows[1] = "This is row " + rows[0];
rows[2] = "Data for row " + rows[0] + " is " + rows[0];
dataGridView1.Rows.Add(rows);
}
Теперь приступим к анализу памяти (working set), требуемого этим приложением. Для начала посмотрим, что нам говорит Process Explorer (sysinternals.com): Working Set: 18896KB, Private Bytes: 20300KB. Эти цифры дают примерное представление о размере памяти, необходимой для процесса. Однако, по ним нельзя сказать для чего используется эта память, сколько в ней кода, данных, сколько потребовалось для GC, и т.д. Скудность этой информации даёт некоторым возможность предположить, что большая часть памяти требуется для GC, что GC выделил её с запасом, и он сможет её освободить и вернуть операционной системе, если потребуется. Чтобы понять действительно ли это так нам нужно получить больше информации о памяти нашего процесса.
Используем vadump (msdn.microsoft.com). Команда “vadump -sop <pid>” даёт нам очень красивое summary:
Она представляет из себя сумму по всем модулям процесса. Всего 8MB, т.е почти половина полной памяти не имеет отношения к GC, а является памятью, которую занимают модули. Причём всего 540KB является private для данного процесса. Остальная память либо разделяется между процессами (5316KB) либо может разделяться (2564KB). Посчитать память требуемую модулями .NET я оставлю как задачку для читателей. Модулями .NET являются: mscorwks, mscorjit, mscoree, и все модули оканчивающиеся на .ni.dll (NI – сокращённо native image – модуль, созданный NGEN’ом).
Теперь перейдём к GC. Где его heap? Память, используемая под GC Heap, vadump называет Other Data:
Category Total Private Shareable Shared
Other Data 2072 8288 8284 4 0
Как видим, разделяемой памяти здесь нет, что очень даже логично. Всего мы имеем 8MB, что само по себе не так плохо, хотя и немало. Однако дальше в этом направлении продвинуться с помощью vadump’а сложно. В частности нельзя получить ответы на такие вопросы как: сколько из этой памяти реально используется объектами, а сколько было выделено GC наперёд для своей работы.
Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).
Итак, запускаем “windbg -p <pid>” и загружаем sos:
0:004> .loadby sos mscorwks
Здесь можно набрать команду !help, чтобы узнать, какие возможности предлагает sos. Нас в данном случае интересует GC Heap, который мы посмотрим следующим образом:
0:004> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x01aacfe4
generation 1 starts at 0x018abfbc
generation 2 starts at 0x01381000
ephemeral segment allocation context: none
segment begin allocated size
0016e7c8 7a721784 7a74248c 0x00020d08(134408)
0016a508 7b451688 7b467f9c 0x00016914(92436)
00155a98 790d6358 790f5800 0x0001f4a8(128168)
01380000 01381000 01b1eff4 0x0079dff4(7987188)
Large object heap starts at 0x02381000
segment begin allocated size
02380000 02381000 02386d98 0x00005d98(23960)
Total Size 0x7fa850(8366160)
------------------------------
GC Heap Size 0x7fa850(8366160)
OK. Видно, что vadump нам не соврал. Действительно GC heap в данный момент отнимает ~8.4MB памяти. Однако, не весь GC Heap занят живыми объектами. Какая-то его часть свободна. Это можно узнать, пройдя по всем объектам в хипе:
Теперь понятно, что свободно у нас около 1.3MB. Это та память, которую GC может в принципе отдать OS, но он этого не сделает, потому как по сравнению с полным размером GC Heap (8.4MB) это очень мало. Для compacting GC нормально иметь вдвое больше памяти, чем требуется для живых объектов.
Чтобы было прикольнее пишу это сообщение с 40 параллельно запущенными тестами в каждом из который торчит тот самый не экономный грид с 10 000 записей каждый. параллельно рабатают еще около 40 процессов среди которых Судтия, Янус
Сто раз зарекался отвечать на фобии вроде твоих, но откровенно говоря что-то внутри подмывает, когда слышу вот такие заявления делаемые со столь серьезным выражением лица и с казалось бы сероезным основанием.
Очень хочется, чтобы после этого ответа ты избавлся от этих фобий или хотя бы перстал стращать ими окружающих поя заупокойную безвременно оставившей нас памяти.
PD>Они у всех ограничены. Все знать нельзя — не DOS времена.
В досе все было не сильно проще. Не думаю, что концепция виртуальной памяти сильно сложнее концепции сегментов или оверлеев.
PD>Настоятельно советую купить. Я серьезно говорю. У меня такое впечатление, что ты (и не только ты, скорее вы все) то ли не хотите, то ли времени нет, то ли еще что-то — но не знаете и не понимаете базовых механизмов функционирования ОС.
Не думай, что ты один знаком с организацией памяти в Виндовс. И так же не думай, что этого достаточно для понимния того как донет управляет памятью.
Со своей стороны вижу у тебя огромные пробелы в области понимания того как работает ЖЦ. И неверную оценку того насколько страшен свопинг для десктоп-приложений. Первое устраняется чтением статей и блогов по организации ЖЦ (не надо про Рихтера, ты его то понял не верно, а в нем о физическом устройстве ЖЦ очень не много сказано).
Второе — это чистая фобия. Экстраполяция проблем разных Мозил на другие приложения.
PD> Отсюда порой анекдотические заявления (и не только твое). А когда человек такие заявления делает, то доверие к тому, что он и по другим поводам говорит , резко падает — он же базу не знает.
Твои заявления посмешнее будут. И главное, многие их за чистую монету моут принять.
PD>Попробую объяснить.
Ты бы понять попробовал. А то обясняешь другим, а сам...
... PD>Мне ничего не стоит сделать Commited Bytes (в Task Manager называется VM Size) для своей програмы большим, чем размер RAM. При этом часть будет выделена в RAM, часть в файлах (свопе, MMF)
Запомни эти свои слова. Они тебе помогут понять то что ускользает от твоего взора.
PD>А вот Working Set — это совсем другое дело. Это те страницы, которые сейчас в RAM. Это то, что твоя программа сейчас забрала себе.
Ага. Для среднего С++-приложения это так и есть. Но вот для дотнет приложения это не совсем так. Оно всегда забирает памяти больше чем ему надо по минимуму. Собственно говоря так поступает почти любое приложение, но в дотнете это очень ярко выражено. Делается это правда не всегда, а только тогда когда в системе есть много свободной памяти (физической).
Улавливашь куда я клоню?
PD>Все процессы начинают работу с фиксированного Working Set (значений под руками нет). Далее они могут запрашивать все больше и больше памяти, VM Size будет у них расти (только они сами могут его потом уменьшить, освободив память) а вот будет ли при этом увеличиваться Working Set — зависит от ситуации в машине. Если памяти RAM свободной много, то будет. Более того, система может даже дать больше, чем максимум (см. SetProcessWorkingSetSize). Если же памяти мало, то система будет вытеснять страницы, а не давать новые.
Вот тут уже видно слабое понимание реальности. Дело в том, что Выньдос отнимает страницы только если оных нехватает в системе. Ну, или при той же минимизации. При этом если приложение продолжает обращаться к памяти, то задействованные страницы быстренько возвращаются обратно приложению.
Рельно если система сама начала отнимать физические странциы (а не пометками заниматься), то мы имеем ситуацию когда "ОС села на своп". Это как раз тот случай когда при переключении к очередному приложению мы слшышим мирное жужание винта. Работать в таких условиях очень неприятно и нужно срочно бежать за новой памятью. Собственно под ХРющей в 64 (да и в 128) метрах если не выгружать ничего такая ситуация наступает очень быстро.
PD>Теперь о минимизации. Разумеется, система отдает предпочтение активному приложению. И вот его минимизировали. Поскольку ты явно заявил, что не будешь с ним работать сейчас (правда это или нет — другой вопрос), то система усекает его Working Set , отнимая у него страницы.
Ага. Но опять таки, как только ты возвращаешся к приложению, то система вынуждена отдавать страницы обратно. И обычно сделав минимизацию, возвратившить в приложение и чуть-чуть подергавшись в нем ты видишь тот объем памяти (физической) который действительно нужен приложению для эффективной работы. Отсальное — это баласт который или вообще не выделен физически процессу (не закомиченая память), или выделен но не используется. С незакомиченой памятью все ясно и так, а вот со врорым случаем нужно разбираться глубже.
Есть два случая когда память выделена, но не исползуется. Первый память закомичена но не использована по назначению. Второй в памяти размещены данные которые используются очень редко. Со втрорым все понятно, но с первым!
"Разумный прораммист", к коим ты себя видимо причесляшь, не будет занимать у системы лушинюю память. Ведь это отнимит ее у других процессов (так видимо ты думаешь), но "дальновидный программист" знающий особенности реализации системы и своих алгоритмов очень даже может рашиться на заем памяти сверх необходимого.
Зачем? Все очень просто. Выделение выртуальной памяти слишком медленно для многих алгоритмов. В то же время отъем выделенной, но не использованной памяти системой при переключении задач практически незаметен. Это доли секунды. Отрисовка и та заметна больше.
Так вот сборка мусора первого и второго поколения проходит быстрее чем заем виртуальной памяти. В то же время ОО-программы очень часто выделяют и освобождают большие массивы временных объектов. При этом получаются эдакие всплески. Занимается груда объектов и практически мгновенно большая их часть помирает. Так как освообождение мертвых объектов ничего не стоит, то выгодно иметь резерв памяти для подобных всплесков.
Более того, ЖЦ вообще работает эффективно только если в куче есть некоторый (и довольно значительный) объем памяти. Таковы уж алгоритмы сборки мусора.
Вот и выходит, что очень не малая часть памяти управляемого процесса — это банально неиспользуемая память. Отнимать ее не дорого если это делается не часто.
PD>А их куда девать ? Зависит от того, попадут ли они в список простаивающих или модифицированных. Если это страницы кода, то в первый (скорее всего), если данных — во второй (опять же скорее всего). Простаивающие страницы — кандидаты на выделение их другому процессу (после обнуления), модифицированные надо прежде того записать на диск , а потом уж давать другим.
Вот вот. Только незанятую память тоже нет смысла своповать. Ее ведь даже перечитывать не прийдется.
PD>Так чот уменьшить Working Set можно мгновенно практически — просто объявить эти страницы более не принадлежащими процессу, и все. Никакой записи на диск при этом вообще не произойдет.
Вот, вот. И не всегда прийдется эту память вообще куда-то записывать. А раз так, то чем является боязнь ворксета кроме как фобией?
Ведь же все просто... памяти в системе море... ЖЦ это видет и вместо того чтобы собрать мусор принимает решение увеличить ворксэт. Более того, чтобы делать это шустро он не просто занимает память, а делает это с запасом. Точнее это делается сегментами виртальной памяти по 16 метров и комитами по необходимости (но довольно большими кусками). Причем память будучи занятой не спешит освобождаться так как скорее всего ее еще раз запросят.
Вот и выходит, что ворксет у приложения 65 метров, а размер памяти отведеной под кучи составляе мегабайт 8. Или размер кучи 40 метров, но в основном он приходится на нулевое и первое поколение которое если что моментально можно собрать и таким образом отбросить или на разреженную кучу которая после сборки сильно уменьшится, но сборку не делают, так как памяти выше крыши.
PD>Теперь сам можешь понять, что происходит. Минимизировали приложение. Уменьшился резко Working Set. А дальше что будет — зависит от a) много ли RAM и b) насколько агрессивно новый процесс (с которым теперь начали работать) запрашивает память и как давно с ним не работали.
Намного больше зависит от того как само приложение начнет востанавливать ворксет после активизации. Если оно сбросило ворксет до 5 метров и в системе мало свободной памяти, то приложение может и не начать набирать ворксет.
Так например, ворксет теста с гридом возрастает до 40-60 метров когда в системе свободно 900 метров памяти (из 2 Гб) и практически не привышает 30 метров когда в системе объем занятой памяти превышает объем оперативки (без учета свопа). Мои 40 процессов в основном держутся в рамках 30-15 метров. Если памяти станет меньше, то система отест еще. Но до момента пока система не сядет на своп скорость переключения на любой из процессов будет практически молниеносной (не заметной для человека). Вот сейчас я переключился на проивольный тест и никаких тормозов. Переключение на давно не используемую студию тоже к свопу не привело. А между тем ТаскМенеджер показывает 1.56 гига при 1 Гб установленном в системе.
PD>Если RAM много, а преемник не агрессивный, то отложенную запись будут откладывать . Некуда спешить — в системе тихо и мирно, всем памяти хватает.
Ага. И не забываем, что неиспользованную памяь вообще никуда девать не нужно.
PD>У меня на машине этот эффект проявляется, к примеру на Mozilla. Она у меня запущена всегда и я с ней почти не работаю, могу час-два к ней не обращаться. Если запустить некий процесс, активно отъедающий память, а потом переключиться на Мозиллу — тормоза очень заметны.
Боюсь Мозила тут не сильно виновата, но как многие С++-приложение оно почти всегда поднимает 90% своего ворксета при активизации. В сочетании с кончиной памяти в системе ты и видишь своп.
PD>Так что чудес не бывает. Суммируя, могу сказать- если процесс захватил 60 Мб Working Set и эти данные не R/O, то их записывать на диск будут (разве что процесс убьют, тогда, мб, и не будут). Но, конечно, не немедленно, а когда потребуется. И если таких процессов много (а минимизация, как сам понимаешь, отнюдь не гарантирует, что процесс не будет ничего делать, это лишь в большинстве случаев так), то свопинг будет хороший. Но размазанный по времени, так что ощутит юзер тормоза или нет — от многих факторов зависит.
Значит чудеса бывают, так как 60 метров виртуалки превращаются в 14 или даже 8 при большей забивке памяти в системе или меньшем ее наличии.
Ты привык к тому, что ворксет приложения одинаков независимо от того в каких условиях оно запущено. Но для ЖЦ-процессов это не так. Виртуалка и ворксет ЖЦ-процессов регулируются. ЖЦ способен отдавать память системе если ей ее нехватает, и обходиться скромными запасами. Но если памяти в системе много ЖЦ способен получать выгоду от ее количества. Таковы уж алгоритмы ЖЦ, что они работают быстрее если занимают больше памяти. Ведь чем больше хипы первого и нулевого поколения, тем реже их нужно убирать. А чем реже их нужно убирать, тем выше вероятность, что все временные объекты умерли к моменту сборки.
По этому одно и то же приложение будучи запущенное на машине с 2 Гб памяти и при отсуствии программ-конкурентов легко демонстрирует 60-и метровый ворксет и довольствуется 15 метрами на машине с 500-ами метрами и в более тесном окружении. А на машине со 128 метрами она вообще возможно ужмется в 10 метров или менее.
Да, несомненно расход памяти и у дотнета, и у новых контролов больше чем у доисторических ListView и жлобском С-коде не использующем даже динамической памяти. Но и писать "бережливый" код в сотни раз сложнее и неудобнее. Результат же при этом получается куда более убогим и на много позже.
С точки зрения же нормального пользователя разницы особой нет. Ну, если конечно его не душит жаба при виде цифири 60 Мб в таскменеджере на его новой машине с 2 Гб оперативки.
PD>Поэтому , кстати, ASP.NET пользуется большой популярностью, а WinForms — нет.
Во как? Забавно. А откуда статистика? Я что-то вижу, что все больше и больше дескнопного софта пишется на дотнете. У меня добрая половина процессов уже желтенькие в ПроцессЭксплорер. Утилиты все сплош ирядом на нем написаны. Даже бэкап на сервере и то на нем. А уж о создании ГУИ для разных учетных и управленческих систем и говорить не приходится. На С++ его пишут уже куда реже.
PD> Для ASP.NET процесс-то, по существу, один — aspnet_wp.exe. Даже если там пять сайтов крутится и пользователей из Интернета тысяча. А вот если все приложения на рабочей станции перевести на .Net — будет тихий ужас. Если простенький пример Влада ухитрился иметь 60 Мб Working Set (хоть убей, не понимаю, как такого можно добиться!
Как видишь Влад запустил 40 экземляров того же приложения на машине с вдвое меньшим объемом памяти (да еще и ноутбуке с хреновым винтом супротив AMD 3500+ со Strip-ом на двух 7000-тысячниках). И никаких тормозов и свопинга предрекаемых тобой не произошло. А ведь казлось бы ты почти доказал обратное!
PD> Если бы от меня потребовали такое на Win32 написать — отказался бы, не знаю, как это можно сделать — то при десятке таких приложений будет примерно то, как работа Windows 95 на 4 Мб. Не пробовал ? MS тогда заявила, что будет работать (3.1 прекрасно работала). Я и попробовал
Я пробовл. Windows 95 на 4 метрах с сетью практически не работали. Дум на свопе это было что-то... Входишь в комнату... трррр... отсвоповали комнатку... бежим до следующей двери... Правда без сети можно было ворд загрузить, но жить было все равно не здорово. 4 метра это для 3.1. А Windows 95 бегать начинали от 8 метров. И то чуть по больше программка и хана. А уж чтобы загрузить 90 процессов как это у меня происходит сейчас когда я пишу эти строки, такого я даже вообразить не мог.
Сейчас же я сижу с гигом и казалось бы не столь экономной ХРюшей и спокойно запускаю 90 более половины из которых менеджед-процессы.
PD>Надеюсь, теперь понял, что это не фикция ? И опять-таки, твое поведение меня удивляет. Ну не понимаешь, ладно, ничего страшного, поищи информацию, почитай, поймешь же без труда, не так уж это сложно. Но зачем же фикцией называть, если ты не понимаешь ? Лучше сначала разобраться, а потом и не захочется фикцией называть.
Золотые слова. Вот прочитай их и пойди разберись в том, что ты пыташся обсуждать. А то ведь право вводишь в заблуждение людей по чем зря. Ну, нельзя на базе общих знаний о виртуальной памяти обсуждать ЖЦ.
PD>И последнее. ИМХО у тебя сложилось впечатление, что я противник .Net. Вовсе нет. В целом я ее существование только приветствую, и отдаю ей должное. Хорошая система.
Да, оно и видно. Ты еще ни одного ее хая не пропустил.
PD> Но не надо ее возможности преувеличивать.
А кто это делает? Можно примеры?
PD> Поэтому я смотрю на вещи трезво.
Здравствуйте, VGn, Вы писали:
VGn>Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то
Ты не прав. Павел не первый и не единственный, кто обратил внимание на манеру общения VladD2.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
A>[поскипал всё ]
A>Супер, Павел, просто супер. Но до здравого смысла этих людей пробиться сложно. Упорные они. Я пытался. Мало что выходит: A>http://rsdn.ru/Forum/Message.aspx?mid=965653&only=1
Здравствуйте, ie, Вы писали:
ie>А почему?!
Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше таких резких переходов — тем ниже коэффициент сжатия и тем хуже конечный результат. Хуже всего — черный текст на белом фоне.
GIF оптимизирован под большие площади, залитые одинаковым цветом, а также под изображения с малым количеством использованных цветов.
Большинство скриншотов используют относительно мало цветов, и относительно много текста/рамочек. Поэтому применение JPEG для них — симптом абсолютного непонимания автором цифровых форматов изображений.
З.Ы. Естественно, сие не догма. Если скриншот должен продемонстировать как раз существенно полутоновые особенности — типа градиентов в заголовках или полупрозрачности окошек — то, конечно, жпег велкам.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Какая же она резидент, если приложение сминимайзил — и вот она уже foreign? Или ты правда полагаешь, что винда успевает за 0.1 секунды флашнуть на диск 60 мегабайт? Мне б такой контроллер.
Слушай, ну не надо. Возьми Соломона — Руссиновича, "Внутреннее устройство Windows 2000" (вышло новое издание по XP/2003, но я его не видел) почитай про рабочее множество, про отложенную запись модифицированных страниц и ее алгоритмы (простаивающие страницы, модифицированные страницы, когда именно и как происходит запись модифицированных страниц), про рабочие потоки в процессе System и т.д. Ты же явно этой информацией не владеешь, иначе такое бы не говорил. Зачем чепуху говорить ?
Вот выдержки оттуда (на диске есть только английский текст)
As you'll recall, the term used to describe a subset of virtual pages resident in physical memory is called a working set. There are two kinds of working sets—process working sets and the system working set.
You can use the Performance tool to examine process working set sizes by looking at the following performance counters:
Counter Description
Process: Working Set Current size of the selected process's working set in bytes
Process: Working Set Peak Peak size of the selected process's working set in bytes
Process: Page Faults/Sec Number of page faults for the process that occur each second
Several other process viewer utilities (such as Task Manager, Pview, and Pviewer) also display the process working set size.
S>Вот, вот он ключ к ответу! Как-то слабо зависит быстродействие системы от от отожранной дотнет приложениями памяти.
Антон, честное слово — почитай. Тебе самому стыдно будет читать, что ты здесь написал.
Вообще меня удивляет в тебе одно. Ты прекрасно разбираешься во многом. Но зачем ты делаешь заявления в том, в чем ты явно не разбираешься — это я понять не могу.
S>Она не съела. А взяла напрокат. Попросишь — отдаст.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я вот одно не пойму в ваших с Владом рассуждениях. С точки зрения пользователя ПК все эти внутренние дела .Net, для изучения которых годится профайлер — интереса не представляет. Есть объем рабочего множества, он у Влада был 60 Мб на 10000 строках в гриде. Зачем он такой нужен — меня как пользователя не касается, а вот захватить 60 Мб под грид с 10000 записями — это суметь надо! Лично я за решение такой задачи на Win API, пожалуй , не возьмусь — фантазии не хватит, на что 60 Мб употребить
Какой ты пользовтель? Нормальный пользователь работает, а не байты считает. Ты скорее скряга сохнущая над перерасходом 10 мег из гигабайта.
А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине. В SQL Server 2005 ее заменила отличная IDE на основе VS 2005 и того самого "прожорливого" грида. Работать стало удобно. Возможностей стало больше. Памяти жрется под 100 метров в некоторых случаях, но блин, что мне до того? 10 студий мне открывать и не хочется (хотя это и не проблема).
PD>А страницы эти, между прочим, скорее всего модифицированными помечены. Так что при их вытеснении (при минимизации) им в своп-файл идти придется. Даже если их оттуда обратно брать не будут...
Психолог. Однозначно требуется психолог...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kedik, Вы писали:
K>А как процесс Дотнета узнает что в системе ресурсов нехватает (память в данном случае)? Есть информация или хотя бы идеи по поводу как это происходит?
Из книги "Customizing .NET Framework Common Language Runtime", глава 13.Managing How the CLR Uses Memory (см выделенное жирным):
If you need to constrain or otherwise customize how the CLR uses memory, use the CLR hosting API to implement a memory manager. Implementing a memory manager enables you to customize the following aspects of how memory is managed in your process:
Virtual memory management
Heap management
File mapping functions
Reporting the current memory load to the CLR
These capabilities are provided by the three interfaces that make up a memory manager: IHostMemoryManager, IHostMalloc, and ICLRMemoryNotificationCallback. As the primary interface in the hosting manager, IHostMemoryManager is the interface the CLR asks the host for during initialization. The CLR determines whether a host implements the memory manager by passing the IID for IHostMemoryManager to the GetHostManager method of the host's implementation of IHostControl. (Refer to Chapter 2 for a complete description of how the CLR determines which managers a particular host implements.)
The equivalent of the Win32 GlobalMemoryStatus API is the GetMemoryLoad method on IHostMemoryManager. The CLR will call GetMemoryLoad periodically to determine the memory load on the system from the host's perspective. The host returns two values from GetMemoryLoad, as shown in the following definition from mscoree.idl:
The first parameter, pMemoryLoad, is the percentage of physical memory that is currently in use. This parameter is equivalent to the dwMemoryLoad field of the MEMORYSTATUS structure returned from GlobalMemoryStatus. The pAvailableBytes parameter is the number of bytes that are currently available for the CLR to use.
The exact behavior of the CLR in response to the values returned from GetMemoryLoad isn't defined and is likely to change between releases. That is, returning specific values doesn't guarantee that a specific amount of memory will be freed or even that a garbage collection will be done immediately. All that is guaranteed is that the CLR considers the values returned from GetMemoryLoad when determining the timing of the next garbage collection.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Читать — разделяемая память в ОС Windows. При запуске n раз одного и того же приложения приличная часть памяти есть общая память.
Можешь хоть как "оче наш" заучить Рихтера и Русиновича, но разумность оценок от этого лучше у тебя не станет. В совренменных ОО-программах основная память тратится под объкты. Код обычно не привышает 10%. Так что разделять особо нечего. Да и не много программ имеет смысл запускать по десять раз.
VD>>Ага. Но опять таки, как только ты возвращаешся к приложению, то система вынуждена отдавать страницы обратно. И обычно сделав минимизацию, возвратившить в приложение и чуть-чуть подергавшись в нем ты видишь тот объем памяти (физической) который действительно нужен приложению для эффективной работы. Отсальное — это баласт который или вообще не выделен физически процессу (не закомиченая память),
PD>Вот на этом я особо хочу остановиться. Потому как эта фраза попросту демонстрирует твое непонимание самих основ вирт. памяти.
Моя версия — непонимание присутствует у тебя.
PD>Что это за балласт, который вообще не выделен процессу (не закомиченная память) ?. Что это вообще такое ?
PD>Незакоммиченным (а только зарезервированным) может быть только адресное простанство, а не память.
Ты выдрал цитату из контекста. Там еще два пункта было. Про незакомиченную память я сказал для полноты картины. Незакомиченное конечно адресное простанство.
PD> И это называется резервированием адресного пространства и дерезервированием. PD>Никакой памяти вообще при резервировании или дерезервировании АП не выделяется и не освобождается.. И сбрасывать этот резервированный регион на диск имеет смысл не более, чем сбросить на диск математическое пространство .
Ты удивишся, но закомиченная, но неиспользогванная память тоже на диск не сбрасывается.
PD>Резервирование или дерезервирование могут повлиять на VM Size — общий объем резервированных адресов. Но уж никак не на Working Set — потому что это объем страниц, в настоящее время находящихся в RAM.
Серьезно? А ты точно хорошо своего Русиновича прочел? Ты все напутал.
Я же большей частью говорил про ворксет и выделенную но неиспользованную память. После минимизации и востановаления ворксет приходит к 5-10 метрам. И как ты собирашся отделать что там в свопе, а что просто отдали системе? Ведь из 60 метров 40 могли быть просто неиспользованной закомиченой памятью. А 20 реально выделенной. Причем из этих 20 где нибудь 10 метров могут быть редко используемыми или вообще баластом (которому самое место в свопе).
Ты уперся в ворота и не хочешь признать банального факта. Дотнет отдает ресурсы системе если ей их нехватает. Он банально собирает мусор и уменьшает кучу. Посему смотреть на цифири получающиеся на машинах с 2 гигами ничем не занятыми просто бессмыслнно. Пускай от того что дотнет сожрал лишних 40 метров производительность увеличилась на 3%. Но она увеличилась. За что его можно ругать то? Память то попросу не используется.
PD>Вот и все. Советую все же прочитать книги по основам ОС, чтобы чепуху не писать.
С своей стороны советую убрать свой менторский тон и пойти учиться дальше. А то ты возмонил себе, что знашь все лучше других и поучашь всех на право и на лево. Не беспокойся за чужие знания. Я тоже читал и Рихтора и Русиновича. И не хуже тебя понимаю, что такое виртауальная память и с чем ее едят. Причем знаю это не по наслышке, так как сам сижу на NT со времен когдаона была еще 3.5. А вот ты судишь о том, в чем явно не разбирашся — о ЖЦ. И твои поучения выглядят просто смешно. Не признавать очевидные вещи конечно можно, но выглядишь приэтом глупо.
Сейчас не времена доса. Памяти сотни мег и нет смысла экономить ее в ущерб удобству и надежности. Темболее не стоит закатывать истерик плавно переходящих в компании по ловле ведьм тольно на основании того, что программа с новым гридом на машине с 2 гигами сожрала 60 мег. В конце концов это 3%. Зато на то чтобы сэмулировать возможности этого грид на ListView у тебя уйдет вся оставшаяся жизно. Разница между ними не меньше чем между Excel и SuperCalc.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>В трехсотвосьмидесятый раз повторяем: совершенно не факт, что все эти мегабайты действительно заняты.
Печально, что тебе тристовосьмидесятый раз хочется что-то заявить, не посмотрев в хелп по тому же Task Manager. Вот что там написано (выделено мной)
Memory Usage
In Task Manager,the current working set in kilobytes. The current working set is the number of pages currently resident in memory
Понимаешь — resident. Тут уж ни убавить, ни прибавить.
S>Павел, ты уже определись — интересуют тебя "страницы и своп", или таки нет. А то как тебе профайлер предлагают, посмотреть, как там что устроено — так сразу нос воротим. Зато как начать предполагать на уровне страниц подкачки — это всегда пожалуйста.
Я давно определился.
Как пользователя (или администратора) — не интересует абсолютно. Равно как, к примеру, не интересует, как куча в Win32 устроена или стек. Меня только одно интересует — рабочее множество процесса и количество операций подкачки на pagefile или других файлах (ну и другие счетчики taskman или perfmon, рекомендации, за какими счетчиками стоит следить, можешь посмотреть в курсе по администрированию). Потому что от этого зависит быстродействие системы и то, насколько программы уютно себя чувствуют в ней. И какие аргументы бы не приводились насчет того, как там это внутри устроено, я как пользователь знаю одно — если сейчас Memory Usage == 60 Мб, значит, из 768 Мб физической RAM у меня эта программа 10% примерно съела.
Здравствуйте, _Artem_, Вы писали:
_A_>Мы бы хотели добавить еще памяти, да ктож нам ее даст, а на свои деньги покупать жаба давит . А на 256 или хуже того 128 это будут жутко тормозить
А кто тебе сказал, что этот самый грид будет тормозить на 128 метрах? Ты пробовал?
Ну, да опять таки... если требования экономить память не фига использовтаь гриды написанные в 2005-ом году в рассчете на новую технику. Пользуйся тем же ListView. Хотя реально это конечно фобии.
Ну, а тормоза у тебя скорее появятся не от нехватки памяти, а от передачи 10 000 записей по сети.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, parapet, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
<все аналогии skipped>
P>есть такая крылатая фраза — горе от ума Чем глубже мы погружаемся в какую-либо область и чем более ясны логические цепочки — тем тяжелее нам представить что-либо, что не вписывается в наши логические выводы в этой области. Об этом нужно всегда помнить — такова специфика нашего мозга — обладая глубокими знаниями о чем-либо — наш мозг отбрасывает все, что идет вразрез с этими знаниями Птицы тоже не должны летать, т.к. они тяжелее воздуха. И в теорию относительности я не верю (уж больно какая-то она сухая), несмотря на то, что логически она очень даже выстроена
Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.
P>Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.
Нет. Это не вопрос. Дело в том, что пока не появится ОС, в которой .Net в ядре, до тех пор программы .Net есть просто процессы Windows. И в этом плане они ничем не отличаются от других процессов. И об их поведении надо судить по тем средствам, которые Windows предоставляет для изучения поведения процессов. Вот и все. Как они там внутри устроены — это их внутреннее дело. Чистые Win API приложения — так-то, приложения .Net — иначе, приложения FoxPro — еще как-то и т.д. Свою систему напишешь — еще что-то будет. А с точки зрения ОС это все процессы, 3 кольцо.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Однозначно требуется специалист, способный отучить тебя от хамства. Боюсь только, что это никому не под силу.
Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.
а может и не круглая. А если и круглая — то для некоторых задач мы вполне можем ее рассматривать как плоскую. И результаты будут достаточно точны.
P>>Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.
PD>Нет. Это не вопрос. Дело в том, что пока не появится ОС, в которой .Net в ядре, до тех пор программы .Net есть просто процессы Windows. И в этом плане они ничем не отличаются от других процессов. И об их поведении надо судить по тем средствам, которые Windows предоставляет для изучения поведения процессов. Вот и все. Как они там внутри устроены — это их внутреннее дело. Чистые Win API приложения — так-то, приложения .Net — иначе, приложения FoxPro — еще как-то и т.д. Свою систему напишешь — еще что-то будет. А с точки зрения ОС это все процессы, 3 кольцо.
ну есть немножко издержки по притеснению процессов, есть. Но как ни крути нельзя сказать про программу на .НЕТ что она сожрала 60 метров памяти. Вот если сишная сожрала — так это сожрала, ты хоть убейся не отдаст она 50 метров за короткое время. Так что тут заявлять что .НЕТ программа сожрала в прямом смысле слова 50 метров — ну это слишком громко сказано...
Здравствуйте, VladD2, Вы писали:
L>>Я что-то не увидел в твоем сообщении никакого намека, что это всего-лишь твое мнение.
VD>Это может твое мнение "всего-лишь", если тебе так угодно считать. А мое мнение вполне себе мнение без приставок всего и лишь. И намекать тут в общем-то не о чем. Если я считаю, что-то, то это и есть мое мнение.
Здравствуйте, VladD2, Вы писали:
VD>В общем-то это очеведные вещи и любой кто задумается над сутью вопроса может прийти к выводам сам, но почему-то большинство людей упорно не хотят думать и раз за разом наступают на те же грабли.
Здравствуйте, mrozov, Вы писали:
M>Во всем этом форуме нет наверное ни одного человека, который бы этого не понимал. Это очевидно. Но ты единственный, кто понимает, при чем тут это!
Еще и авторы выпущенного под эгидой Микрософт книги по внутренненму устройству Windows. Они понимают именно то, о чем я пишу, потому что я их высказывания и озвучиваю — сам я Windows не дизассемблировал. Правда, в этоим форуме они не участвуют, но им я как-то доверяю больше, чем всем участникам этого форума — в таких вопросах
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
Мне кажется вы зря иронизируете.
Вопрос не в языке, а в том, что в .NET есть GC, который умеет эффективно реагировать на просьбы подвинуться.
Собственно именно это вам сказали уже много раз.
Здравствуйте, _Artem_, Вы писали:
_A_>Здраствуйте форумчане!
_A_>Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
.Net сьедает сколько ему "позволят". Куда ушли 40 МБ можно посмотреть например при помощи CLRprofiler или SOS.DLL + debugger
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>По большому счету, вообще — то, это их проблемы. Им же хуже, если на то пошло
VD>Проблемы скорее у тех котому ты умудришся голову запудрить. Причем данный вопрос в общем-то мало интересен. Но вот твои посажи по абстракциям — это действительно супер. Ну, да будем надеяться, что твои ученики свою голову на плечах имеют.
К сожалению, я сдела одну ошибку, в которой вынужден признаться. Ошибка в том, что я возобновил дискуссии с тобой. Дискутировать ты не умееешь, вместо этого переходишь на хамство. Поэтому вынужден отказаться впредь от каких-либо дискуссий с тобой.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>В трехсотвосьмидесятый раз повторяем: совершенно не факт, что все эти мегабайты действительно заняты.
PD>Печально, что тебе тристовосьмидесятый раз хочется что-то заявить, не посмотрев в хелп по тому же Task Manager. Вот что там написано (выделено мной)
PD>Memory Usage
PD>In Task Manager,the current working set in kilobytes. The current working set is the number of pages currently resident in memory
PD>Понимаешь — resident. Тут уж ни убавить, ни прибавить.
Какая же она резидент, если приложение сминимайзил — и вот она уже foreign? Или ты правда полагаешь, что винда успевает за 0.1 секунды флашнуть на диск 60 мегабайт? Мне б такой контроллер.
PD>Как пользователя (или администратора) — не интересует абсолютно. Равно как, к примеру, не интересует, как куча в Win32 устроена или стек. Меня только одно интересует — рабочее множество процесса и количество операций подкачки на pagefile или других файлах (ну и другие счетчики taskman или perfmon, рекомендации, за какими счетчиками стоит следить, можешь посмотреть в курсе по администрированию). Потому что от этого зависит быстродействие системы и то, насколько программы уютно себя чувствуют в ней.
Вот, вот он ключ к ответу! Как-то слабо зависит быстродействие системы от от отожранной дотнет приложениями памяти. PD>И какие аргументы бы не приводились насчет того, как там это внутри устроено, я как пользователь знаю одно — если сейчас Memory Usage == 60 Мб, значит, из 768 Мб физической RAM у меня эта программа 10% примерно съела.
Она не съела. А взяла напрокат. Попросишь — отдаст.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине. В SQL Server 2005 ее заменила отличная IDE на основе VS 2005 и того самого "прожорливого" грида. Работать стало удобно. Возможностей стало больше. Памяти жрется под 100 метров в некоторых случаях, но блин, что мне до того? 10 студий мне открывать и не хочется (хотя это и не проблема).
А вот мне нравится Query Analyzer, тем более что от него много и не требуется выполение запросов и построение их планов плюс просмотр информации по таблицам ...
А 100 мб. памяти отожрать это же как постараться нужно, может они там в Microsoft сговорились с разработчиками памяти и отжирают ее специально
Здравствуйте, parapet, Вы писали:
P>ну есть немножко издержки по притеснению процессов, есть. Но как ни крути нельзя сказать про программу на .НЕТ что она сожрала 60 метров памяти. Вот если сишная сожрала — так это сожрала, ты хоть убейся не отдаст она 50 метров за короткое время. Так что тут заявлять что .НЕТ программа сожрала в прямом смысле слова 50 метров — ну это слишком громко сказано...
Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
Абстрагируясь от вышескзанного, это действительно так.
Дело в том что программы на C# общаются с ОС не напрямую (как в случае C++), а через .NET Framework. И этот framework в свою очередь может откушивать у ОС памяти больше, чем требует прикладная задача на c#. Например, чтобы ее эффективнее (с его, framework'а, точки зрения) отдавать потребителям.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Как я понял из дальнейшего обсуждения, ты последовательно игнорируешь все рассуждения опонентов про GC, мотивируя это тем, что чудес не бывает и .net от с++ для win ничем не отличается — перед богом все равны.
Ок.
Допустим, я напишу программу (на чистом c++, разумеется), которая при запуске (и далее по таймеру в 30 секунд) делает одну простую вещь — отжирает ровно 10% от имеющейся свободной памяти. Если выясняется, что программа уже отожрала больше 10% оной — она ее освобождает.
Далее, мы запускаем эту чудо-программу (must have) на машине с гигом свободной памяти — и видим, что она отожрала 100 Мб!!!
Нетрудно подсчитать, что система сможет одновременно выдержать не больше 10 экземпляров оной. Не удивительно, что программы на c++ теряют популярность — при такой-то прожорливости.
Подтвердим теорию практикой — запустим второй экземпляр. Однако он почему-то занял только 90 Мб — странно. Проверив через какое-то время первый экземпляр обнаруживаем, что он теперь занимает 81 Мб — вообще мистика!
А запустив 100 экземпляров получаем (после того, как устаканится своп ) вполне работоспособную систему. Выходит, что с++ не так уж и плох! (В моем примере все 100 экземпляров будут постоянно циклически перестраивать занимаемый собой объем памяти, но это издержки наглядности)
Что мы имеем? Мы имеем систему, которая на первый взгляд кажется черезвычайно прожорливой, а на самом деле — это только фикция. Т.е. модель .net-а.
Я думаю, что теперь настало самое время вернуться к рассмотрению вопроса о том, нафига .net ведет себя таким образом — но это тебе на разные лады повторяли уже раз тридцать по меньшей мере — для эффективности и экономии ресурсов машины.
Здравствуйте, mrozov, Вы писали:
M>Здравствуйте, Pavel Dvorkin,
M>Просто результат наблюдений.
M>Как я понял из дальнейшего обсуждения, ты последовательно игнорируешь все рассуждения опонентов про GC, мотивируя это тем, что чудес не бывает и .net от с++ для win ничем не отличается — перед богом все равны.
Именно так. Все действия GC — внутреннее дело .Net. А для Windows — это процесс, и он подчиняется правилам поведения любых процессов.
Если не согласен — OK, приведи мне какие-нибудь ссылки на то, что ядро Windows хоть что-то знает о .Net и в состоянии отличать процессы .Net от других.
Подчеркиваю — ядро. Все остальное меня просто не интересует, так кая если ядро не знает — то обращаться с процессом .NET оно будет, как и со всеми остальными процессами.
M>Ок.
M>Допустим, я напишу программу (на чистом c++, разумеется), которая при запуске (и далее по таймеру в 30 секунд) делает одну простую вещь — отжирает ровно 10% от имеющейся свободной памяти. Если выясняется, что программа уже отожрала больше 10% оной — она ее освобождает. M>Далее, мы запускаем эту чудо-программу (must have) на машине с гигом свободной памяти — и видим, что она отожрала 100 Мб!!! M>Нетрудно подсчитать, что система сможет одновременно выдержать не больше 10 экземпляров оной. Не удивительно, что программы на c++ теряют популярность — при такой-то прожорливости.
M>Подтвердим теорию практикой — запустим второй экземпляр. Однако он почему-то занял только 90 Мб — странно. Проверив через какое-то время первый экземпляр обнаруживаем, что он теперь занимает 81 Мб — вообще мистика!
Если она у тебя имеет коммитированную память 81 Мб — срочно ищи у себя ошибку, так как она сама декоммитировала 19 Мб . А если речь идет о рабочем множестве, то оно может быть и 10 Мб, и 5 и даже 0 вообще.
M>А запустив 100 экземпляров получаем (после того, как устаканится своп ) вполне работоспособную систему. Выходит, что с++ не так уж и плох! (В моем примере все 100 экземпляров будут постоянно циклически перестраивать занимаемый собой объем памяти, но это издержки наглядности)
M>Что мы имеем? Мы имеем систему, которая на первый взгляд кажется черезвычайно прожорливой, а на самом деле — это только фикция. Т.е. модель .net-а.
Нет. Мы имеем просто-напросто процесс усечения рабочего множество ОС Windows для неактивных процессов (потоки которых находятся в состоянии "не готовы")
M>Я думаю, что теперь настало самое время вернуться к рассмотрению вопроса о том, нафига .net ведет себя таким образом — но это тебе на разные лады повторяли уже раз тридцать по меньшей мере — для эффективности и экономии ресурсов машины.
M>Ага?
Почитай книги по функционированию ОС и системных механизмах.
Здравствуйте, TK, Вы писали:
TK>А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать TK>то, что сборка мусора выполняется в моменты когда это необходимо. Кроме TK>этого, надо учитывать то, как именно считается объем занимаемой памяти. TK>Значение в 40Mb совершенно не означает, что это именно физическая память.
Меня это заинтересовало, решил проверить. С БД возиться неохота, поэтому просто создал форму, на нее листбокс, и такой вот код
private void Form1_Load(object sender, System.EventArgs e) {
for( int i = 0; i < 10000; i++)
listBox1.Items.Add("0000" + i);
}
После этого Ctrl-Alt_Del и имеем
Debug
Mem Usage 9,900 Mb
VMSize 10,284 Mb
Release
Mem Usage 8,576 Mb
VMSize 8.972 Mb
А потом сделал я приложение MFC. SDI + такой вот код
for( int i = 0; i < 10000; i++)
{
CString str;
str.Format("0000%d", i);
m_LB.AddString(str);
}
Debug
Mem Usage 4,036 Mb
VMSize 1,504 Mb
Mem Usage 3,084 Mb
VMSize 1,068 Mb
И, наконец, чистый Win API. Листбокс засунул в About Dialog
for (int i = 0; i < 10000; i++)
{
char szBuf[20];
sprintf(szBuf, "0000%d", i);
SendDlgItemMessage(hDlg,IDC_LIST1,LB_ADDSTRING, 0, (LPARAM)szBuf);
}
Debug
Mem Usage 2,840 Mb
VMSize 1,068 Mb
Release
Mem Usage 2,808 Mb
VMSize 1,008 Mb
Проверял на нескольких запусках. Отличия есть, в пределах 100 Kb.
Здравствуйте, _Artem_, Вы писали:
_A_>Здраствуйте форумчане!
_A_>Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
Здравствуйте, Lloyd, Вы писали:
L>>>Зря ты так. Ее очень не хватает в 2005-ом.
VD>>Если ты так считашь, то надыбать старый клиент не проблема.
L>Наверное, можно, конечно. Но не уверен что он будет работать с новым 2005-м сервером. По крайнеи мере EM работать не очень-то желает.
Работает. Жаль что в Managment Studio убрали "Scripting Options". Эх...
Hello, "_Artem_" > > И вообще нормально ли что .Net столько отъедает?
А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать
то, что сборка мусора выполняется в моменты когда это необходимо. Кроме
этого, надо учитывать то, как именно считается объем занимаемой памяти.
Значение в 40Mb совершенно не означает, что это именно физическая память.
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
VD>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти, то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта. Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
Да уж, замечательно.
Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем.
Имхо, психологические проюлемы у тех, кто не понимает что в некоторых ситуациях, это дело может действительно тормозить.
Не всегда на машине по гигу памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>ВыньФормс-приложение с DataGridView VD>>заполненным 10 000 строк (с одной колонкой) VD>>после изнурительного скролинга по всем VD>>строкам 60 496 61 032
PD>Win32 приложение с 10 000 строк после PD>изнурительного скроллинга по всем строкам 2 816 1 008
Я тебе уже сказал. Поставь на машину 64 метра и опрадуйся от того, что и дотнетное приложние заняло 2-3 метра.
И еще раз для упертых до неприличия товарищей повторяю, что не стоит сравнивать объемы занимаемой памяти в управляемой куче при работе одного контрола, с объемами занимаемыми в неуправляемой куче при работе другого контрола. Как минимум контролы разные. Ну, а то что хипы разные и ведут себя по разному об этом уже как бы и говорить стыдно, так как можно это трактовать как обвинение собеседника в проблемах с памятью (личной) .
VD>>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти
PD>Без всяких психологических проблем 10 приложений по 60 Мб скушают всю память,
Вы батенька мошенничаете. Сравниваете совсем разные вещи и делаете далеко идущие выводы. Я кажется привел характеристики пустого приложения и приложения с ListView.
К тому же я довольно внятно продемонстрировал, что реально занимается виртуалка. И что если другим процессам/потокам требуется физическая память, то она немедленно возвращается в систему.
PD> даже если некоторые из них будут минимизироваться (что еще не означает, что они не будут работать, между прочим).
Минимизация сбрасывает ворксет. После востановления окна ворксет становится таким каким он действительно нужен приложению (по минимому). А до этого ЖЦ занимает столько памяти, сколько считает разумным. Запустив приложение на машине с 20 гигами можно получить и пару сотен мег. А запустив на 64 просто пару.
>> то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта.
PD>Хороший способ полемики, ничего не скажешь!
Это не способ. Это факт. У тебя чисто психологические проблемы. Жадность проще говоря. Жалеишь цифирьки.
>>Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
PD>А в чем, собственно, тут оптимизация произошла, можно узнать ?
В том, что сборка мусора не ведется до тех пор пока это действительно не потребуется.
PD>Win32 приложение так же великолепно показывает и скроллирует листбокс, как и .Net приложение.
Ты сам выбрал задачу где скорость не то что не критична, но и вообще мало интересна. ЖЦ еще не столь умен, чтобы определять где нужно оптимизировать скорость, а где объем занятой памяти.
Что же до скорости, то на 64 метрах под NT4 память дотнетным приложением будет так же заниматься куда меньше, а скорость по прежнему будет уператься в видиокарту и алгоритмы отрисовки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Да уж, замечательно. А>Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем.
Понимаеш ли в чем дело... Такова уж жизнь. С удешевлением реуросов и увеличением их объемов программисты начинают выбирать более чистные решения потребляющие больше ресурсов, нежели грязные и хакерские, но экономящие память.
Причем реальные траты памяти не так уж и велики. Ведь занимается неиспользуемамя память. Если вдруг память нужна системе она отадется. Да и тормоза — это слишком громко сказано. Работа ЖЦ конечно шустрее если есть большой запас по памяти, но до тех пор пока ОС не села на своп проблем особо заметно не будет. Да скорость будет ниже. Да при переключении между задачами будет задержка размеров в 0.3-1 секунду. Но фактически пользователь
А>Имхо, психологические проюлемы у тех, кто не понимает что в некоторых ситуациях, это дело может действительно тормозить. А>Не всегда на машине по гигу памяти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, VGn, Вы писали:
VGn>>Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то
L>Ты не прав. Павел не первый и не единственный, кто обратил внимание на манеру общения VladD2.
Просто Влад когда идет в крестовый поход бывает рубит не глядя...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, parapet, Вы писали:
P>>ну есть немножко издержки по притеснению процессов, есть. Но как ни крути нельзя сказать про программу на .НЕТ что она сожрала 60 метров памяти. Вот если сишная сожрала — так это сожрала, ты хоть убейся не отдаст она 50 метров за короткое время. Так что тут заявлять что .НЕТ программа сожрала в прямом смысле слова 50 метров — ну это слишком громко сказано...
PD>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
PD>Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.
господи, ну сколько можно повторяь — ла она занимает память, но она, в отличие от отожранных С++ программой тех же 60 мб, быстро ее отдаёт. В этом и отличие. И так есть на практике. Вся теория не стоит и выеденного яйца если не подтверждается на практике. Хотя в данном случае теория верна, только ты смотришь на нее с одной стороны...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.
а я советую тебе поменьше читать серьезной лит-ры, т.к. ты уже за серьезной литературой не видишь что происходит в реальности.
Откровенно говоря, большого желания спорить нет, устал я с тобой спорить, да и тон твой мене уже надоел порядком. Поэтому отвечу лишь на 2 пункта
VD>Чтобы было прикольнее пишу это сообщение с 40 параллельно запущенными тестами в каждом из который торчит тот самый не экономный грид с 10 000 записей каждый. параллельно рабатают еще около 40 процессов среди которых Судтия, Янус
Читать — разделяемая память в ОС Windows. При запуске n раз одного и того же приложения приличная часть памяти есть общая память.
VD>Ага. Но опять таки, как только ты возвращаешся к приложению, то система вынуждена отдавать страницы обратно. И обычно сделав минимизацию, возвратившить в приложение и чуть-чуть подергавшись в нем ты видишь тот объем памяти (физической) который действительно нужен приложению для эффективной работы. Отсальное — это баласт который или вообще не выделен физически процессу (не закомиченая память),
Вот на этом я особо хочу остановиться. Потому как эта фраза попросту демонстрирует твое непонимание самих основ вирт. памяти.
Что это за балласт, который вообще не выделен процессу (не закомиченная память) ?. Что это вообще такое ?
Незакоммиченным (а только зарезервированным) может быть только адресное простанство, а не память. И это называется резервированием адресного пространства и дерезервированием. Никакой памяти вообще при резервировании или дерезервировании АП не выделяется и не освобождается.. И сбрасывать этот резервированный регион на диск имеет смысл не более, чем сбросить на диск математическое пространство .
Резервирование или дерезервирование могут повлиять на VM Size — общий объем резервированных адресов. Но уж никак не на Working Set — потому что это объем страниц, в настоящее время находящихся в RAM.
Вот и все. Советую все же прочитать книги по основам ОС, чтобы чепуху не писать.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
MS>Мне кажется вы зря иронизируете. MS>Вопрос не в языке, а в том, что в .NET есть GC, который умеет эффективно реагировать на просьбы подвинуться.
Вот , кстати, тот же простой пример.
.Net, Листбокс, 10000 строк
Запустили
Mem usage(т.е. Working set) — 8.736 Mв
VM Size (коммитированная память) — 8.972 Mb
Минимизировали
Mem usage(т.е. Working set) — 592 Кв
VM Size (коммитированная память) — 8.924 Mb
Т.е при минимизации система по своей инициативе урезает рабочий набор. Коммитированная память остается
практически без изменения, а Working Set она резко уменьшает.
Только вот .Net здесь ни при чем. Так все приложения себя ведут.
Mozilla
Mem Usage сейчас 20.832
VM Size — 22.532 Mb
Минимизировали
Mem Usage 1.516
VM Size — 22.508 Mb
Тот же эффект, даже более ярко выраженный.
А теперь Мозиллу развернем, но сначала посмотрим на Page Faults. Оно сейчас 25,078
Mem Usage 11.784 (полистать письма — увеличится)
VM Size — 22.404 Mb
Page Faults — 26,985
Page Fault — это обращеие к диску, так как больше брать неоткуда
(26985-25078) * 4Kb = 7628 Kb
В действительности больше. Дело в том, что Windows использует алгоритм загрузки страниц с кластеризацией. Иными словами, читается за 1 раз не страница, а блок последовательно лежащих.
Вот эти 8 Мб и перекачали с диска при максимизации. Их и откачали при минимизации до этого.
А теперь мой листбокс развернем
Page Faults
До разворачивания — 4924
После — 5171
(5171 — 4924) * 4 Kb = 988 Кв
Поменьше, намного меньше, но ведь мой листбокс далеко не Мозилла
Ну и Mem Usage растет понемногу.
В общем, никакой разницы я не вижу между управляемыми и неуправляемыми приложениями в этом плане
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>По большому счету, вообще — то, это их проблемы. Им же хуже, если на то пошло
Проблемы скорее у тех котому ты умудришся голову запудрить. Причем данный вопрос в общем-то мало интересен. Но вот твои посажи по абстракциям — это действительно супер. Ну, да будем надеяться, что твои ученики свою голову на плечах имеют.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>К сожалению, я сдела одну ошибку, в которой вынужден признаться. Ошибка в том, что я возобновил дискуссии с тобой. Дискутировать ты не умееешь, вместо этого переходишь на хамство. Поэтому вынужден отказаться впредь от каких-либо дискуссий с тобой.
Замечательно. За одно откажись от своих высказываний по дотнету, так как в основном они являются откровенной пропагандой ахинее. И именно они вызвают нездоровые дискуссии и общее раздражение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>OK. Видно, что vadump нам не соврал. Действительно GC heap в данный момент отнимает ~8.4MB памяти. Однако, не весь GC Heap занят живыми объектами. Какая-то его часть свободна. Это можно узнать, пройдя по всем объектам в хипе: A>
A>Теперь понятно, что свободно у нас около 1.3MB. Это та память, которую GC может в принципе отдать OS, но он этого не сделает, потому как по сравнению с полным размером GC Heap (8.4MB) это очень мало. Для compacting GC нормально иметь вдвое больше памяти, чем требуется для живых объектов.
Меня больше привлек такой момент: Free + System.String = 3121016 — что как раз таки показывает прожорливость System.Windows.Forms, а отнюдь не прожорливость GC.
Потому что они при этом получаются хренового качества, не выигрывают в размерах и не пригодны для какй-бы то нибыло дальнейшей обработки.
Скриншоты нужно записывать в GIF (если цветов мало, до 255) или в png.
В jpeg же имеет смысл записывать только фотографии и многоцветные картинки. Вот тут jpeg дает и оптимальное сжатие, и jpeg-артефакты мешают не особо сильно. Правда и тут нужно умудриться не переборщить со степенью сжатия, так как на максимальных степенях jpeg способен угробить любую фотогнафию.
В общем-то это очеведные вещи и любой кто задумается над сутью вопроса может прийти к выводам сам, но почему-то большинство людей упорно не хотят думать и раз за разом наступают на те же грабли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).
А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ie, Вы писали:
ie>>А почему?! S>Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше
Он не "основан на предположении о том", а просто лучше подходит для таких случаев. А как и все алгоритмы сжатия с потерями основан на том что: любую ф-цию (даже и произвольную кривую и прямоугольные колебания) можно представить набором синусоид (гармоник). И чем больше степень сжатия, тем больше высших гармоник мы убираем, тем грубее приближение полученой суперпозиции оставшихся гармоник. Резкие границы как-раз представляют пример прямоугольного колебания, а в этом случае для более точного приближения результирующей кривой к исходной необходимы как раз высшие гармоники.
Для интересующихся см. раздел высшей математики "Ряды Фурье". Раздел этот появился еще задолго до jpeg-ов и алгоритмов сжатия, в 18 веке вроде.
Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
Здравствуйте, VladD2, Вы писали:
VD>ВыньФормс-приложение с DataGridView VD>заполненным 10 000 строк (с одной колонкой) VD>после изнурительного скролинга по всем VD>строкам 60 496 61 032
Win32 приложение с 10 000 строк после
изнурительного скроллинга по всем строкам 2 816 1 008
VD>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти
Без всяких психологических проблем 10 приложений по 60 Мб скушают всю память, даже если некоторые из них будут минимизироваться (что еще не означает, что они не будут работать, между прочим).
> то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта.
Хороший способ полемики, ничего не скажешь!
>Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
А в чем, собственно, тут оптимизация произошла, можно узнать ? Win32 приложение так же великолепно показывает и скроллирует листбокс, как и .Net приложение.
Здравствуйте, TK, Вы писали:
TK>А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать TK>то, что сборка мусора выполняется в моменты когда это необходимо.
Мы загружаем список договоров для просмотра из базы данных. Их где-то 10000 штук. Здесь уже некуда их девать нада грузить все. К тому же есть еще большие таблицы, которые нужно будет отображать в TreeView, ну да ладно там можно будет заполнять дерево постепенно, по мере раскрытия листов.
TK> Кроме этого, надо учитывать то, как именно считается объем занимаемой памяти. TK>Значение в 40Mb совершенно не означает, что это именно физическая память.
Отжирает именно 40 мб. физической, а не виртуальной памяти.
VD>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти, то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта. Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
Мы бы хотели добавить еще памяти, да ктож нам ее даст, а на свои деньги покупать жаба давит . А на 256 или хуже того 128 это будут жутко тормозить
Здравствуйте, <Аноним>, Вы писали: А>Да уж, замечательно. А>Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем. А>Имхо, психологические проюлемы у тех, кто не понимает что в некоторых ситуациях, это дело может действительно тормозить. А>Не всегда на машине по гигу памяти.
Очень рекомендую все-таки натравить на приложение дотнет мем-профайлер и посмотреть, что и куда уходит. Оценить реальные расходы памяти. Прикинуть, как это будет себя вести на системах с меньшим количеством RAM.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Очень рекомендую все-таки натравить на приложение дотнет мем-профайлер и посмотреть, что и куда уходит. Оценить реальные расходы памяти. Прикинуть, как это будет себя вести на системах с меньшим количеством RAM.
Я вот одно не пойму в ваших с Владом рассуждениях. С точки зрения пользователя ПК все эти внутренние дела .Net, для изучения которых годится профайлер — интереса не представляет. Есть объем рабочего множества, он у Влада был 60 Мб на 10000 строках в гриде. Зачем он такой нужен — меня как пользователя не касается, а вот захватить 60 Мб под грид с 10000 записями — это суметь надо! Лично я за решение такой задачи на Win API, пожалуй , не возьмусь — фантазии не хватит, на что 60 Мб употребить
А страницы эти, между прочим, скорее всего модифицированными помечены. Так что при их вытеснении (при минимизации) им в своп-файл идти придется. Даже если их оттуда обратно брать не будут...
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Я вот одно не пойму в ваших с Владом рассуждениях. С точки зрения пользователя ПК все эти внутренние дела .Net, для изучения которых годится профайлер — интереса не представляет.
Рассуждения очень простые. Удивляюсь, почему их приходится столь многократно и многословно повторять. PD>Есть объем рабочего множества, он у Влада был 60 Мб на 10000 строках в гриде. Зачем он такой нужен — меня как пользователя не касается, а вот захватить 60 Мб под грид с 10000 записями — это суметь надо!
В трехсотвосьмидесятый раз повторяем: совершенно не факт, что все эти мегабайты действительно заняты. Это раз. Во-вторых, почему-то в большинстве случаев такие PD>А страницы эти, между прочим, скорее всего модифицированными помечены. Так что при их вытеснении (при минимизации) им в своп-файл идти придется. Даже если их оттуда обратно брать не будут...
Павел, ты уже определись — интересуют тебя "страницы и своп", или таки нет. А то как тебе профайлер предлагают, посмотреть, как там что устроено — так сразу нос воротим. Зато как начать предполагать на уровне страниц подкачки — это всегда пожалуйста.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Слушай, ну не надо. Возьми Соломона — Руссиновича, "Внутреннее устройство Windows 2000" (вышло новое издание по XP/2003, но я его не видел) почитай про рабочее множество, про отложенную запись модифицированных страниц и ее алгоритмы (простаивающие страницы, модифицированные страницы, когда именно и как происходит запись модифицированных страниц), про рабочие потоки в процессе System и т.д. Ты же явно этой информацией не владеешь, иначе такое бы не говорил. Зачем чепуху говорить ?
Конечно, мои знания ограничены. Но тебе же незнание основ устройства дотнета не помешало критиковать его?
У меня нет под рукой Соломона-Руссиновича.
Возможно, я что-то неверно понимаю. Но ты не мог бы мне пояснить, как именно Working Set процесса влияет на остальные процессы? Вот у меня типичное количество свободной физической памяти ~ 500 mb. Это означает, что отожранные янусом мегабайты никому не жмут. Я также заметил, что янус отжирает не фиксированное количество памяти. Когда у меня было 525 метров — он тратил 30 метров. Сейчас — 112. Process Explorer при этом показывает 94.6 MB Private Bytes. Он же показывает 45 мегабайт во всех хипах дотнета. (Это все три поколения + Large Objects Heap). При этом Reserved = 92 Mb. То есть на всякий случай дотнет держит полсотни метров памяти про запас. Что-то мне подсказывает, что эти байты можно при нужде легко отдать.
Вот я сминимайзил януса — и его working set стал 1.5 Мb. Примерно за полсекунды. То есть когда у меня таки кончатся эти 500 метров свободной памяти (что означает, что я запустил какой-то еще фотошоп), янус подвинется и отдаст. PD>Антон, честное слово — почитай. Тебе самому стыдно будет читать, что ты здесь написал. PD>Вообще меня удивляет в тебе одно. Ты прекрасно разбираешься во многом. Но зачем ты делаешь заявления в том, в чем ты явно не разбираешься — это я понять не могу.
Я не делаю заявлений. Я не понимаю, почему начинаются сказки про прожорливость приложений, которую так трудно заметить. Я не вполе понимаю все это многообразие цифр, которые показывают различные перформанс тулы. Я вижу, что весь этот Working Set — это фикция, поскольку легким манием руки он прыгает с 400 до 2, а потом до 30М.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ничего удивительного
PD>if(lowMemory) PD> VirtualAlloc (еще) PD>else PD>// как-нибудь обойдемся тем, что есть
PD>И если в коде Януса такого явно и нет, то это не значит, что такого нет в .Net Framework или в исполняющей системе.
ты хочешь сказать что оно моментально скидывает в своп?
Здравствуйте, VladD2, Вы писали:
VD>А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине.
Зря ты так. Ее очень не хватает в 2005-ом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Память и .Net
От:
Аноним
Дата:
28.04.06 10:21
Оценка:
Интересный топик, видно основные проблемы нынешних IT.
Даже боюсь предложить изучать СУ(Р)БД.
P.s. Р в скобках, поскоку других не знаю
Здравствуйте, parapet, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
<skipped>
Просто вызовите SetProcessWorkingSetSize(hProc,-1,-1) и посмотрите сколько она сожрала... А потом посчитайте сколько занимают в память 10000 (кажется) строк в гриде... и подумайте, а стоит ли удивляться вообще
Здравствуйте, Lloyd, Вы писали:
VD>>А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине.
L>Зря ты так. Ее очень не хватает в 2005-ом.
Если ты так считашь, то надыбать старый клиент не проблема. Я же считаю то что считаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Зря ты так. Ее очень не хватает в 2005-ом.
VD>Если ты так считашь, то надыбать старый клиент не проблема.
Наверное, можно, конечно. Но не уверен что он будет работать с новым 2005-м сервером. По крайнеи мере EM работать не очень-то желает.
VD>Я же считаю то что считаю.
Я что-то не увидел в твоем сообщении никакого намека, что это всего-лишь твое мнение.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Память и .Net
От:
Аноним
Дата:
28.04.06 14:23
Оценка:
Отличный топик получился! Не поленился — прочитал все!
1. Спасибо за то, что хорошо подискутировали на тему памяти — многое для себя устаканил в голове.
2. Собственно по проблеме грида: в упор не понял зачем целиком грузить в память весь список, если в гриде видны несколько (десятков) строк. Это примерно тоже самое, что и пытаться прорисовать ВЕСЬ список, хотя он не влезает на экран.
Вот сколько разных гридов я ни использовал и какие только сумасшедшие объемы через них ни проходили, но всегда проблема памяти не стояла — в памяти были только текущие записи + кэш, который содержал следующую страницу и\или первую\последнюю для быстрой реакции на Home\End.
Вообще не представляю кому пришла в голову идея грузить все — решение же очевидно...
Здравствуйте, Lloyd, Вы писали:
L>Наверное, можно, конечно. Но не уверен что он будет работать с новым 2005-м сервером.
Будет. Гарантирую.
VD>>Я же считаю то что считаю.
L>Я что-то не увидел в твоем сообщении никакого намека, что это всего-лишь твое мнение.
Это может твое мнение "всего-лишь", если тебе так угодно считать. А мое мнение вполне себе мнение без приставок всего и лишь. И намекать тут в общем-то не о чем. Если я считаю, что-то, то это и есть мое мнение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Антон, честное слово — почитай. Тебе самому стыдно будет читать, что ты здесь написал. PD>Вообще меня удивляет в тебе одно. Ты прекрасно разбираешься во многом. Но зачем ты делаешь заявления в том, в чем ты явно не разбираешься — это я понять не могу.
Я плякаль. Ты обвиняешь Синклера в том, чем постоянно занимаешься сам, а именно в обсуждении тем в которых ты ни ухом ни рылом. Замечательный пример обсуждение ЖЦ и джита. К тому же еще делаешь предположения о знаниях собеседника (в основном не верные предположения надо заметить).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.
Вот ты очень похож на такого человека.
P>>Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.
PD>Нет. Это не вопрос. Дело в том, что пока не появится ОС, в которой .Net в ядре, до тех пор программы .Net есть просто процессы Windows. И в этом плане они ничем не отличаются от других процессов. И об их поведении надо судить по тем средствам, которые Windows предоставляет для изучения поведения процессов. Вот и все. Как они там внутри устроены — это их внутреннее дело. Чистые Win API приложения — так-то, приложения .Net — иначе, приложения FoxPro — еще как-то и т.д. Свою систему напишешь — еще что-то будет. А с точки зрения ОС это все процессы, 3 кольцо.
Учи матчасть. ЖЦ следит за объемом свободной памяти в системе и уменьшает свои апетиты если ее становится меньше. Он тот час же собирает мусор и освобождает все назадействованные экстенты. Так же он умеряет потребности и не захватывает лишней памяти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?
PD>Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.
Нда... Ужас. Он же тебе открыты текстом говорит, что объем занимаемой памяти зависит от наличия свободной памяти в системе!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Artem_, Вы писали:
TK>> Кроме этого, надо учитывать то, как именно считается объем занимаемой памяти. TK>>Значение в 40Mb совершенно не означает, что это именно физическая память.
_A_>Отжирает именно 40 мб. физической, а не виртуальной памяти.
почитай тред — да, это физическая память в понимании ОС, но она только зарезервирована. По просьбе ОС ее вернут назад.
У тебя массивный объект в памяти. Следовательно, ты склонен оперировать с большими объектами в памяти. мало ли что ты захочешь сделать — например, склонировать этот объект еще 5 раз. Что, просить память каждый раз у системы, которую еще выдадут фрагментированной?
Здравствуйте, parapet, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.
P>а я советую тебе поменьше читать серьезной лит-ры, т.к. ты уже за серьезной литературой не видишь что происходит в реальности.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Резервирование или дерезервирование могут повлиять на VM Size — общий объем резервированных адресов. Но уж никак не на Working Set — потому что это объем страниц, в настоящее время находящихся в RAM.
Маленькое уточнение. Даже на VM Size (в смысле Task Manager) резервирование повлиять не может , так как это объем коммитированной памяти. Для получения объема резервированного пространства надо использовать , например, Process Viewer.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Чтобы было прикольнее пишу это сообщение с 40 параллельно запущенными тестами в каждом из который торчит тот самый не экономный грид с 10 000 записей каждый. параллельно рабатают еще около 40 процессов среди которых Судтия, Янус
PD>Читать — разделяемая память в ОС Windows. При запуске n раз одного и того же приложения приличная часть памяти есть общая память.
Если ты о коде dll-ек, то ты не совсем прав. Сама она, может быть и шарится, да только вот заjitеный код м/у процессами уже не шарится.
L>Если ты о коде dll-ек, то ты не совсем прав. Сама она, может быть и шарится, да только вот заjitеный код м/у процессами уже не шарится.
Вот насчет заjitеный код высказываться не буду, так как здесь некомпетентен. Меня не интересует, как там в самой .Net, а я просто говорю о процессе. А в нем шарятся все страницы, которые read/only и те страницы, которые явно или неявно на WRITE_COPY механизме (код,ресурсы) до попытки модификации страницы. Разумеется, речь идет о тех страницах, которые имеет смысл шарить. Страницы стека потока не шарятся
А jit-code, действительно, скорее всего не шарится, поскольку с точки зрения Windows это приватные страницы, которые вначале были данными (когда джиттер туда код загонял), а потом стали кодом.
Но вообще-то количество кодовых страниц всегда намного меньше, чем страниц данных. Одну хорошую bmp в ресурсы — и будет больше, чем весь код серьезного приложения
Здравствуйте, Andy77, Вы писали:
ВВ>>Т.е. читать 10000 записей в грид — это нормально, а root of all evil — это дотнет? A>Бывает, что и нормально, нам ведь ничего не известно про его задачу.
Ну почему не известно. В этой ветке она довольно подробно обсуждалось.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А чего вы хотите ?
ВВ>Т.е. читать 10000 записей в грид — это нормально,
С точки зрения интерфеса с пользователем — no comments. Я на эту тему не высказывался вообще и не хочу. Истина конкретна, а задачи я в деталях не знаю.
С точки зрения хранения в ОП 10000 элементов — вполне нормально. Грид, в конце концов, просто хранилище для них. В массиве миллион элементов — это нормально ? ИМХО вполне нормально.
Здравствуйте, VladD2, Вы писали:
VD>Ты уперся в ворота и не хочешь признать банального факта. Дотнет отдает ресурсы системе если ей их нехватает. Он банально собирает мусор и уменьшает кучу. Посему смотреть на цифири получающиеся на машинах с 2 гигами ничем не занятыми просто бессмыслнно. Пускай от того что дотнет сожрал лишних 40 метров производительность увеличилась на 3%. Но она увеличилась. За что его можно ругать то? Память то попросу не используется.
VladD2,
не в коем случае не ставлю под сомнение твою информацию...
но у меня возник теоретический вопрос, с сугубо практическим интересом:
А как процесс Дотнета узнает что в системе ресурсов нехватает (память в данном случае)? Есть информация или хотя бы идеи по поводу как это происходит?
Здравствуйте, kedik, Вы писали:
K>А как процесс Дотнета узнает что в системе ресурсов нехватает (память в данном случае)? Есть информация или хотя бы идеи по поводу как это происходит?
Чтобы не повторяться просто процитирую свои слова из статьи GC в .NET
Есть три причины, вызывающих запуск процесса сборки мусора:
1. При очередном выделении памяти GC замечает, что превышен размер нулевого поколения.
2. Приложение самостоятельно вызывает метод GC.Collect().
3. Нехватка памяти в ОС.
Самой частой причиной является пункт 1. Пункт 3 обычно является большой редкостью. Ну а пункт 2 зависит от программиста, но обычно тоже крайне редок. Однако в Windows-приложениях пункт 2 может быть инициирован подсистемой учета ресурсов ОС (хендлов).
Пункты 3 приводит к сборке мусора второго поколения. GC.Collect() позволяет указать, какое поколение необходимо «подмести». А вот пункт 1 заставляет GC задуматься. Ход его мыслей приблизительно следующий: «Ага! Надо проверить лимит второго поколения. Если он превышен, то собрать его. Если нет, то проверить лимит первого поколения. Если он превышен, то собрать первое поколение. Иначе собрать только нулевое поколение».
Информация почерпнута из блогов и путем эксперементов. И судя по этой информации в каждом процессе есть некий код следящий за состоянием ОС. К сожалению он не так разумен как хотелось бы, что иногда приводит к печальным последствиям. Например, в той же статье описан вот такой случай:
Нехватка памяти
Всем известно, что при нехватке физической памяти приложение начинает сбрасывать в файл подкачки (swap file) редко используемые части занятой оперативной памяти.
Происходит это, когда приложению нужно памяти больше, чем на данный момент свободно в системе. При этом ОС в первую очередь пытается сбросить свои внутренние буферы (например, кэш файловой системы). Если этой памяти не хватает, начинается «свопинг».
Если память, сброшенная в файл подкачки, действительно используется редко, то замедление получается не такое уж большое. Ведь обращение к памяти относительно локализовано, и swapping производится не часто. Однако файл подкачки – это обычный дисковый файл, а скорость работы дисковой подсистемы в тысячи раз медленнее, чем скорость оперативной памяти.
Чтобы вы могли оценить затраты, связанные с подкачкой, я создал синтетический тест, в котором сначала занимается гандикап – огромное количество памяти (под 10 миллионов объектов, каждый из которых содержит массив длиной от 1 до 128 байт), а затем, не освобождая эту память (храня ссылки на объекты в массиве), производится эмуляция стандартной работы приложения (занимаются и освобождаются объекты). В результате создается ситуация, при которой во время эмуляции стандартной работы объем занятой оперативной памяти превышает объем физической памяти, доступной в этот момент в системе (в системе было установлен гигабайт оперативной памяти и параллельно было замещено немало приложений, общий объем занимаемой ими памяти приблизительно был равен 400 мегабайтам).
Основной тест написан на C# и, естественно, занимает память в управляемой куче. Также я создал аналогичные тесты на C++, занимающие память в обычной куче Windows, и модификацию C++-теста, занимающую память с использованием библиотеки QuickHeap (http://gzip.rsdn.ru/article/cpp/QuickHeap.xml
), ускоряющей работу с памятью в C++-приложениях за счет использования более быстрого, но более прожорливого алгоритма.
Все три теста выполняются сначала с миллионом объектов в качестве гандикапа, а затем – с 10 миллионами. В первом случае объем занимаемой памяти, хотя и велик, но не превышает объема свободной памяти в системе, в которой производилось тестирование. Во втором случае объем гандикапа приблизительно равен объему оперативной памяти в системе. Расчет делается на то, что в обоих случаях после занятия гандикапа приложение не трогает принадлежащие к нему объекты. Вместо этого оно начинает интенсивно выделять большое количество объектов, не удерживая ссылки на них в управляемом тесте, и освобождая объекты в неуправляемых тестах. Таким образом, в основной части теста работа одновременно ведется с небольшим количеством объектов и, соответственно, памяти.
Ниже приведены результаты C++-теста, использующего стандартную кучу Windows:
e:\MyProjects\Tests\Perf\CppNew2\release>CppNew2.exe
Timestamp: 4.238123 sec.
ObjCount=11001000
e:\MyProjects\Tests\Perf\CppNew2\release>CppNew2.exe
Timestamp: 37.864712 sec.
ObjCount=20001000
Значение ObjCount – количество объектов, создаваемых при работе теста, включая как гандикап, так и рабочие объекты. Как видите, второй тест сильно отстал от первого, но отставание все же уложилось в разумные рамки (порядка 10 раз).
Если последить за картиной занятия памяти, то наблюдается следующее. При запуске с миллионом объектов объем занятой виртуальной памяти быстро поднималась примерно до 100 мегабайт и держалась на этом уровне до конца теста. Объем workset-а так же быстро достигал 100 мегабайт и так же неизменно держался до окончания теста.
При запуске теста с десятью миллионами объектов картина в корне отличалась. Сначала и workset и объем виртуальной памяти быстро достигали отметки в 400+ мегабайт. Далее объем виртуальной памяти продолжал постепенно (уже не так быстро) расти, а объем workset-а начал падать и стабилизировался на отметке 10-12 мегабайт (это объем занимаемый объектами, одновременно живущими на стадии «эмуляции обычной работы приложения»).
Совершенно ясно, что если бы приложение начало во время работы обращаться к предварительно занятым объектам (тем самым 10 миллионам), то все было бы значительно печальнее, так как при этом начался бы постоянный свопинг, и основное время тратилось бы на работу с винчестером.
Ради удовлетворения любопытства я повторил тот же тест с использованием своей библиотеки QuickHeap:
e:\MyProjects\Tests\Perf\CppNew2\release>CppNew2.exe
Timestamp: 2.193539 sec.
ObjCount=11001000
e:\MyProjects\Tests\Perf\CppNew2\release>CppNew2.exe
Timestamp: 14.508904 sec.
ObjCount=20001000
Забавно, что даже в условиях свопинга она показала намного лучший результат, чем стандартная куча Windows. Забавно это потому, что QuickHeap достигает своего быстродействия за счет перерасхода памяти. Но еще забавнее было наблюдать за картиной выделения памяти.
При запуске с миллионом объектов объем занятой виртуальной памяти скакнул к ~130 мегабайтам, что существенно выше, нежели в тесте с кучей Windows, но объем workset-а вырос всего ~96 мегабайт! Таким образом, получается, что QuickHeap хотя и тратит больше памяти, но обеспечивает лучшую локализацию данных (по крайней мере, при первом обращении).
Запуск теста с 10 миллионами предварительно занятых объектов привел к очень быстрому занятию порядка гигабайта виртуальной памяти и довольно быстрому увеличению этого объема до 1.3 гигабайта (напомню, что куча Windows постепенно росла вплоть до отметки в 1 гигабайт). Затем объем виртуальной памяти стабилизировался. Workset рос плавно (но быстро) до отметки в 400 мегабайт, после чего столь же плавно (но столь же быстро) спустился до отметки 14-9 мегабайт.
Большую скорость QuickHeap я в данном случае могу объяснить именно лучшей локальностью данных, что вызвало меньшее количество циклов свопинга. Так что хотя общее количество виртуальной занятой памяти было больше, но обращений к диску (как не странно) оказалось значительно меньше.
Ну, а что же GC? Для GC подобный тест оказался самым плохим паттерном использования. Вот его результаты:
e:\MyProjects\Tests\Perf\GC2\GC2\bin\Release>GC2.exe
00:00:02.1843580
Количество созданных объектов: 11001000
Количество сборок мусора поколения 0: 590
Количество сборок мусора поколения 1: 154
Количество сборок мусора поколения 2: 7
e:\MyProjects\Tests\Perf\GC2\GC2\bin\Release>GC2.exe
00:20:47.7608425
Количество созданных объектов: 20001000
Количество сборок мусора поколения 0: 769
Количество сборок мусора поколения 1: 273
Количество сборок мусора поколения 2: 27
Да-да! Две секунды на тест с миллионом объектов и более 20 минут (!) на тест с 10 миллионами!!! Почему такая разница? Думаю, самые прозорливые уже догадались, почему это так (я запустил параллельно архиватор! – шутка). Секрет заключается в том, что при сборке мусора второго поколения GC «дотрагивается» до всех объектов кучи. А это приводит к тому, что Windows поднимает страницы виртуальной памяти, на которых размещены объекты, с диска в физическую память. Это подтверждает и картина использования памяти. Объем виртуальной памяти начинает расти и очень быстро доходит до ~900 мегабайт. Далее он изменяется очень незначительно. А вот workset начинает постоянно расти и, достигнув отметки в 900 мегабайт, сбрасывается до ~400-500 мегабайт. Далее он снова начинает расти до 900 и снова сбрасывается. Так продолжается на протяжении двадцати минут.
В принципе, это не нормально для сборщика мусора, основанного на поколениях, так как он должен был бы пропихнуть неиспользуемые в данный момент объекты во второе поколение и забыть про них. Но почему-то наличие объектов во втором поколении постоянно подталкивает GC к сборке мусора во втором поколении. Причем делает это он тем чаще, чем больше объем второго поколения. Налицо эвристика. В чем она заключается, не знаю, но учитывать это придется. Скорее всего, столь неразумное поведение GC связано с тем, что сборка мусора второго поколения запускается при нехватке памяти в системе. Получается замкнутый круг: нехватка памяти в системе провоцирует сборку мусора второго поколения, а сборка мусора второго поколения провоцирует поднятие страниц в память. На самом деле, это просчет программистов, писавших GC, так как по-хорошему реагировать нужно было бы на нехватку физической памяти.
Какой из этого можно сделать вывод? GC хорошо ведет себя, только если имеет достаточно свободной памяти. Если workset приложения начинает дергаться, то подбираясь к объему виртуальной памяти, то сбрасываясь, знайте, что, скорее всего, вы заняли слишком много лишней памяти. Большое количество сборок второго поколения также говорит о том, что профиль вашего приложения плохо совместим с эвристиками GC.
Что же делать? Пересмотреть политику создания и удержания в живых объектов. Возможно, отказаться от кэша или подгружать малозначимые данные по требованию. Еще один простой и дешевый совет – купить лишний гигабайт памяти.
Но описанный тест — это чистой воды синтетика которой в жизни не встретишь. Обычно процессы занимают памяти меньше чем физически есть в системе и работают относительно по очереди. К тому же сборка мусора в рельных приложениях освобождает не мало памяти, что устраняет проблемы. Другими словами алгоритм в обычных условиях справляется со своими обязанностями неплохо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот о том и речь. После востановаления фокуса твоя мазила сразу отожрала 10 метров памяти, а не 1 метр как ты писал. Сравни это с тем что происходит в дотнетом приложении когда с 60 объем ворксета падает до 5 при наличии фокуса.
ЗЫ
Ктстати, сохранять скриншоты в jpeg так же неразумно как жалеть неиспользуемую памть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ктстати, сохранять скриншоты в jpeg так же неразумно как жалеть неиспользуемую памть.
А почему?!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[24]: Память и .Net
От:
Аноним
Дата:
05.05.06 05:36
Оценка:
Здравствуйте, ie, Вы писали:
ie>Здравствуйте, VladD2, Вы писали:
VD>>В общем-то это очеведные вещи и любой кто задумается над сутью вопроса может прийти к выводам сам, но почему-то большинство людей упорно не хотят думать и раз за разом наступают на те же грабли.
ie>Ужас!
это снова я (prox@inbox.ru)
точно тут подмечено про память на microsoft'e есть статья кто сколько
и какой объект есть память примерно 40% как ни странно string и grid'ы и и списки и все осталоное
и xml И datatable ну прочем чего ожидать от Microsofta они всегда всем свинью подкладывают
и еще раз повторюсь сделайте из топика статью на сайте хотя бы для озанкомления очень хорошо
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, alexeiz, Вы писали:
A>>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).
БП>А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?
Я привел всего лишь один пример применения SOS. SOS может использоваться для отладки очень многих вещей в .NET.
Process Explorer берет информацию из performance counter'ов.
Здравствуйте, Блудов Павел, Вы писали:
A>>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).
БП>А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?
Согласен, но alexeiz правильно указал, что SoS позволяет разобраться в том на что тратится память более детально.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Хороший анализ и вообще достойное сообщение. Надо его будет в ФАК засунуть.
Однако кое-что ты все таки не учитывашь. Так что добавлю пару слов.
A>Теперь приступим к анализу памяти (working set), требуемого этим приложением. Для начала посмотрим, что нам говорит Process Explorer (sysinternals.com): Working Set: 18896KB, Private Bytes: 20300KB.
Вот первое на что ты не обратил внимание, а стоило бы.
Практически аналогичный тест на моей рабочей машине привел к тому, что верксет и виртуалка процесса разраслась до ~60 МБ.
На моем ноутбуке этот же тес привел к разростанию ворксета до ~35 МБ в когда в системе было еще много памяти и к 15 когда я загрузил по больше процессов.
По уму конечно надо бы поглядеть рассклад по подробнее, но и так видна общая зависимость. Если в ОС есть много свободной памяти, управляемый процесс использует ее более активно.
Кстати, на основании того, что процесс занял всего 18 МБ можно предположить, что на твоей машине объем памяти составляет что-то около 500 метров. Я угадал?
Таким образом рассуждения о том кто занимает память явно зависят от машины на которой проводятся эксперементы, а стало быть делать выводы нужно куда как осторожнее.
A>
A>Теперь понятно, что свободно у нас около 1.3MB. Это та память, которую GC может в принципе отдать OS, но он этого не сделает, потому как по сравнению с полным размером GC Heap (8.4MB) это очень мало. Для compacting GC нормально иметь вдвое больше памяти, чем требуется для живых объектов.
1. 8 МБ — это размер обычного хипа (не LOH) который по умолчанию выделяется для приложения. Так что если реально объектов меньше, то на занимаемой памяти это скажется не сильно.
2. Не надо забывать, что при востановлении приложения в ворксет попадают только те объекты которые используются выполняемым кодом. Для грида — это в основном DataGridViewTextBoxCell и string. А это в худшем случае 960 192 + 1 829 392 = 2 789 584. Учитывая же, что в дотнете строки юникод, и то что их в 3 раза больше чем у ListView (колонок ведь там никто не создавал). Получаетвя вполне себе нормальная картина. Ну, а если учесть то, что память под 10 000 объектов постоянно не нужна, то вообще не ясно о чем беспокоиться.
3. Хотя в начале сообщения была упомянута кнопка сбора мусора, но в рассуждениях про ее использовние так и небыло сказано. Что немного жаль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Я привел всего лишь один пример применения SOS. SOS может использоваться для отладки очень многих вещей в .NET.
+1
A>Process Explorer берет информацию из performance counter'ов.
И тем неменее она куда как удобнее если нужно поглядеть информацию о кучах в целом и статистику сборок мусора. А SoS больше полезен для выявления того куда тратится память.
Добавлю сюда же, что для этих целей так же очень удобно использовать Memory Profiler. Он дает очень интересную статистику.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>З.Ы. Естественно, сие не догма. Если скриншот должен продемонстировать как раз существенно полутоновые особенности
+1
S> — типа градиентов в заголовках или полупрозрачности окошек — то, конечно, жпег велкам.
-1
Даже в этих случаях jpeg самый плохой выбор. Вот почему:
1. Текста на экране все равно будет много, а значит грязь, грязь и грязь...
2. Градиент в заголовках, даже если речь идет о красивых темах в ХРюше все равно состоит из относительно малого набора цветов.
3. Jpeg дает приемущество от того, что уменьшает количество цветовых переходов в градиентах. Используемые алгоритмы основаны на том предположении, что человек не распознает уж очень плавного изменения цветов, и напротив достраивает его мысленно. А такие переходя есть только на труколорных картинках вроде фотографий.
Для очень навороченных скриншотов обычно лучше всего подходит формат png. Он дает очень высокое качество (особенно если это png 24) и замечательное сжатие для рисованых компьютером изображением.
Так что можно считать железным правилом "jpeg не стоит применять для скриншотов". А выбор между GIF и PNG делать на оновании количества цветов в изображении. Если их больше 20 скорее всего лучше подойдет PNG. А если их еденицы, то GIF.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Почитай книги по функционированию ОС и системных механизмах.
Ты хочешь сказать, что я не смогу написать программу, которая принудительно захватит 100МБ? И освободит половину по мере надобности?
Если я тебя правильно понял, то могу порекомендовать тебе почитать вообще хоть что-нибудь, кроме книг по программированию, а еще лучше — съездить в отпуск, погреть кости на солнышке.
Павел, я тебе описал поведение программы, которое было внесено сознательно. Давай двигаться маленькими шажками.
— Пойдем логическим путем.
— Пойдем вместе.
Веришь ли ты в существование программы, которая выделит себе память... скажем в виде массива цифр от 0 до 10 количеством в 100МБ?
Веришь ли ты в существование программы, которая в какой-то момент (скажем по таймеру) освободит половину этой памяти?
Если нет — ну... может мне и в самом деле стоит освежить свои знания ОС... да и вообще сменить профессию.
Здравствуйте, _d_m_, Вы писали: ___>Он не "основан на предположении о том", а просто лучше подходит для таких случаев. А как и все алгоритмы сжатия с потерями основан на том что: любую ф-цию (даже и произвольную кривую и прямоугольные колебания) можно представить набором синусоид (гармоник).
Это упрощенное представление. "Алгоритмы сжатия с потерями" основаны не только на гармоническом разложении. Единственное, что можно с уверенностью сказать обо всех алгоритмах сжатия с потерями — это то, что они все пытаются игнорировать малосущественные подробности. Критерий малосущественности выбирается разработчиком алгоритма.
Кстати, как известно с 18 века, вовсе не любую функцию можно представить конечным набором гармоник. Функция с разрывами потребует бесконечно большого количества гармоник. Для интересующихся см. "явление Гиббса". Именно оно отвечает за грязь вокруг текста даже при максимальном качестве пожатия джпегом. ___>И чем больше степень сжатия, тем больше высших гармоник мы убираем, тем грубее приближение полученой суперпозиции оставшихся гармоник. Резкие границы как-раз представляют пример прямоугольного колебания, а в этом случае для более точного приближения результирующей кривой к исходной необходимы как раз высшие гармоники. ___>Для интересующихся см. раздел высшей математики "Ряды Фурье". Раздел этот появился еще задолго до jpeg-ов и алгоритмов сжатия, в 18 веке вроде.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Так вот, допуская гипотетическую возможность сущестования программы, которая управляет объемом занимаемой памяти в зависимости от общего доступного объема оной, мы приходим к интерестному вопросу.
А именно — какого рожна ты все время всем тыкаешь своими книгами по win32, если такую программу можно написать вообще под любую (вменяемую) OS включая DOS, хотя там это и бесполезно?
Ну а дальше для понимания сути дела остается ма-а-аленький такой шажок. Нужно всего-навсего понять, что именно этим (управлением занятой памятью) управляемая куча и занимается.
Здравствуйте, mrozov, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
M>Веришь ли ты в существование программы, которая выделит себе память... скажем в виде массива цифр от 0 до 10 количеством в 100МБ?
Да
M>Веришь ли ты в существование программы, которая в какой-то момент (скажем по таймеру) освободит половину этой памяти?
Да.
Только одно замечание — освободит коммитированную память в своем процессе. А не страницы ОП в системе. Вот этого ты никак не можешь понять А это совершенно разные вещи.
M>Если нет — ну... может мне и в самом деле стоит освежить свои знания ОС...
Именно.
>да и вообще сменить профессию.
Нет, не обязательно. просто почитать хорошие книги.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ie, Вы писали:
ie>>А почему?! S>Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше таких резких переходов — тем ниже коэффициент сжатия и тем хуже конечный результат. Хуже всего — черный текст на белом фоне. S>GIF оптимизирован под большие площади, залитые одинаковым цветом, а также под изображения с малым количеством использованных цветов.
Совершенно верно. Только одно замечание — а не все ли равно в применении к тому скриншоту, который я сделал ? Ей-богу, правильная передача полутонов меня в от момент мало волновала
PD>Только одно замечание — освободит коммитированную память в своем процессе. А не страницы ОП в системе. Вот этого ты никак не можешь понять А это совершенно разные вещи.
Во всем этом форуме нет наверное ни одного человека, который бы этого не понимал. Это очевидно. Но ты единственный, кто понимает, при чем тут это! Ну давай я теперь буду тебе тыкать, что ты не понимаешь, что никаких страниц вообще нет, а есть только электрические импульсы???
Re[14]: Память и .Net
От:
Аноним
Дата:
28.05.06 09:25
Оценка:
Здравствуйте, VladD2, Вы писали:
L>>Зиг хайль.
VD>Уже 60 лет как Гитлер капут.
С большим интересом прочитал топик от корки до корки. Понял, что тут такие кульные ребята, и дотнет они знают от и до, и неинтересно им это уже, а интересно друг на друга собак спускать и крестовые походы устраивать с битием камнями и тухлыми помидорами.
Ну, а поскольку заявленная тема уж больно близка к моей маленькой проблемке, подумалось: может они между делом и помогут с решением.
А вопрос простой: для ехе всегда можно установить зарезервированный размер хипа и стэка и таким образом получить сколько нужно непрерывного адресного пространства, в java машине тоже можно указать для приложения min max (managed) heap size. А вот в дотнет это как минимум нетривиально. Уверждается, что нужно использовать SetGCHostControl из интерфейса ICorConfiguration. А как сделать это практически? Писать своего хоста?
Только не надо меня .... того ... помидорами
Пожалуйста.
Здравствуйте, TK, Вы писали:
TK>Hello, "_Artem_" >> >> И вообще нормально ли что .Net столько отъедает?
TK>А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать TK>то, что сборка мусора выполняется в моменты когда это необходимо. Кроме TK>этого, надо учитывать то, как именно считается объем занимаемой памяти. TK>Значение в 40Mb совершенно не означает, что это именно физическая память.
Добавлю, что 40МБ также не означает что память эта выделена приложением, память может просто выделяться про запас и для более оптимального использования CLR'ом. При этом если приложение запросит несколько метров памяти, то размер занимаемой памяти может даже и уменьшится с 40 до 30 МБ.
Память выделяется про запас для того чтобы была проводить более эфективное по скорости выделение небольших блоков памяти (десятки килобайт). Кроме того резервное выделение памяти дает возможность CLR использовать память более эффективно с точки зрения фрагментации.
Таким образом, если Task Manager показывает 40 МБ для дотнетного приложения, это означает что приложение либо вообще не использует память либо использует не более 10-20 МБ... Остальное выделяется в целях оптимизации производительности и со временем (если не будет затребована приложением или если у системы начнет заканчиваться память) будет освобождена.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Память и .Net
От:
Аноним
Дата:
22.01.07 23:58
Оценка:
ну скажем так, что при выделении памяти размер занимаемой памяти уменьшится не может, но зато она может уйти в своп.
Здравствуйте, winmike, Вы писали:
W>Здравствуйте, _Artem_, Вы писали:
W>.Net сьедает сколько ему "позволят". Куда ушли 40 МБ можно посмотреть например при помощи CLRprofiler или SOS.DLL + debugger
чтобы не плодить топики на столь популярную тему, хочу спросить такую вещь:
В приложении подтекает память. Выглядит это следующим образом:
1) Формы (а может не только они, просто на на них это лучше видно) становятся в очередь на финализацию и не умирают без волшебных вызовов
Здравствуйте, <Аноним>, Вы писали:
А>2) Часть объектов продолжает висеть в очереди на финализацию. При чем ссылки на них держат не какие-то объекты, а события. А>как это можно интерпретировать?
Так, что нужно отписывать умирающие объекты от событий явно. Можно также погуглить по словам Weak Delegate насчет автоматических решений этой проблемы.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IceG, Вы писали:
IG>Отличный топик получился! Не поленился — прочитал все!
IG>1. Спасибо за то, что хорошо подискутировали на тему памяти — многое для себя устаканил в голове.
Вот только не понятно, кто прав а кто нет, кого слушать .
Тебе так удобно? да. Но это не значит что ты уже не сможешь существовать в более маленьком пространстве. Завтра приедут остальные 4 твоих товарища — и ты в течении 5 минут всё свое барахло стягиваешь к своей койке, ну носки возможно прийдется даже постирать 
1.1.4 stable rev. 510
