Здравствуйте, notacat, Вы писали:
_FR>>Это очень легко: стрим, который внутри себя открывает по необходимости дополнительные стримы N>Ну нет, автор в вопросе вообще стримы не упоминает. В любом случае, позволю себе считать, что тогда стрим ридер был не один, а с кем-то
Автор определённо упоминает созданный им StreamReader, который может быть создан исключительно от стороннего стрима или от строки. По одной строке "читать последовательно несколько файлов" несколько, но затруднительно остаётся один единственный вариант — некий хитрый Stream, передающийся в СтримРидер. Ну или откровенный бред автора
N>Лучше не гадать, а подождать пока автор код покажет. А то на догадках можно тотализатор открывать
ИМХО, в моих рассуждениях относительно того, как через СтримРидер автору удалось "прочесть последовательно несколько файлов" нет никаких догадок, кроме предположения о том, что топикстартер был "в своём уме", как говорится, и знал, что пишет
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Don Reba, Вы писали:
JR>>Если не хочется углубляться в механизмы, то можно принять за аксиому, что управление памятью в Windows писали отнюдь не ламеры. NET'овскую надстройку, я думаю, тоже.
DR>Только, далеко не факт, что ценности этих не-ламеров совпадают с вашими.
Ну с моими-то совпадают Тут дело такое, я подобных обсуждений видел множество, и заканчивались они всегда одним из двух вариантов. Либо автор читал что-нибудь по теме, и вопрос снимался, либо автор разбираться не желал, и уходил со стойким убеждением, что "винда маздай"
Ну а в данной ветке особо-то и говорить не о чем, так как ТС так и не сообщил, откуда он берёт озвученные величины. А почти всегда в таких случаях за источник выбирают те показания из диспетчера, которые к реально занятой процессом памяти имеют наименьшее отношение, такая уж традиция сложилась И причина этому, видимо, всё та-же: у тех, кто знаком с механизмами хотя-бы в общих чертах, подобных вопросов не возникает, а те, кто не знаком, почему-то даже справку диспетчера читать не хотят
Здравствуйте, Flammable, Вы писали:
F>Программа немаленькая, уже написана. Не нравятся мне такие огромные траты памяти впустую.
Если Вы инженер, а не блондинка примеряющая платьице, то у вас должно быть не "не нравится"
а — снижает скорость старта/работы других служб на ...%, требует увеличения аппаратной мощности на ...% и т.д.
И что значит — "впустую"/"не впустую"?
F>Сейчас просто загруженная форма занимает 30 мб памяти. Что можно хранить в 30 мегабайтах?
А какая вам то, инженеру разница?
F>вызов метода GC.Collect()
Читайте документацию — вызов Collect() всего лишь просит приблизить время очередной проверки/очистки.
А если GC видит что свободной памяти полно, то ничего он освобождать толком не будет.
Потому что полная сборка мусора — весьма ресурсоемкая операция.
F>Это же извращенство...
Системы с сборкой мусора ВСЕГДА резервируют больше памяти, чем требуется для актуальных данных.
В зависимости от устройства сборщика — в разы может быть.
Пользуйтесь ЯП с ручным распределением памяти тогда.
F>Потому и спрашиваю, может есть способы сократить объем выделяемой памяти.
Потому и отвечаю что вы не о том паритесь.
Здравствуйте, Skynin, Вы писали:
S>Читайте документацию — вызов Collect() всего лишь просит приблизить время очередной проверки/очистки. S>А если GC видит что свободной памяти полно, то ничего он освобождать толком не будет.
Вы неправы. При вызове GC.Collect() сборка мусора начинается немедленно.
S>Потому что полная сборка мусора — весьма ресурсоемкая операция. F>>Это же извращенство... S>Системы с сборкой мусора ВСЕГДА резервируют больше памяти, чем требуется для актуальных данных.
А это правда. Не стоит вмешиваться в работу сборщика мусора пока это действительно не понадобится.
Может кто нибудь приведет ссылку, где бы кратко пояснялись принципы управления памятью в Windows и .NET?
Здравствуйте, v.a.v, Вы писали:
VAV>Может кто нибудь приведет ссылку, где бы кратко пояснялись принципы управления памятью в Windows и .NET?
Хм, кратко... Хотелось бы мне посмотреть, на такое краткое описание
Начать можно с Рихтера, " Создание эффективных WIN32-приложений". Там, как обычно, упор больше на практическую сторону, однако и обзор общих принципов есть. В принципе, если подойти вдумчиво, то достаточное для практики представление получить можно. Далее, для углубления, можно посмотреть Руссинович, Соломон, "Внутреннее устройство Microsoft Windows" Здесь подход уже куда более фундаментальный. Ну а после, опираясь на эту информацию, уже можно переосмыслить и статьи о работе GC в NET-приложениях.
Спасибо почитал. То что описано в первой части статьи я знаю.
А вот вторая часть(о способах сборки мусора) написана как то сумбурно(или плохо переведено).
Перед запуском сборки мусора все управляемые потоки, кроме потока, запустившего сборку мусора, приостанавливаются.
Параллельная сборка мусора позволяет управляемым потокам продолжать операции во время сборки мусора.
Так параллельно или нет? Наверное все таки и та и так(в зависимости от настроек). Но тогда первая фраза в своем контексте не верна.
Начиная с .NET Framework 4, параллельная сборка мусора заменяется фоновой сборкой мусора.
Сборка для эфемерных поколений во время фоновой сборки мусора называется высокоприоритетной сборкой мусора.Во время выполнения высокоприоритетных сборок мусора все управляемые потоки приостанавливаются.
Когда выполняется фоновая сборка мусора и в поколении 0 распределено достаточное количество объектов, среда CLR выполнит высокоприоритетную сборку мусора для поколения 0 или поколения 1.Выделенный поток фоновой сборки мусора проверяет в частых точках, безопасных для сбора мусора, чтобы определить, не появился ли запрос выполнения высокоприоритетной сборки мусора.В этом случае фоновая сборка мусора приостанавливается, чтобы позволить выполниться высокоприоритетной сборке мусора.После выполнения высокоприоритетной сборки мусора работа выделенного потока фоновой сборки мусора и пользовательских потоков возобновляется.
Фоновая сборка мусора удаляет ограничения на распределение, наложенные параллельной сборкой мусора, так как эфемерные сборки мусора могут выполняться во время фоновой сборки мусора.Это означает, что фоновая сборка мусора может удалить неиспользуемые объекты в эфемерных поколениях, а также при необходимости может расширить во время сборки мусора для поколения 1.
Фоновая сборка мусора в настоящее время недоступна для сборки мусора сервера.
Получается что фоновая сборка это некий гибрид между параллельной и не параллельной сборкой.
Изображения почему то не отображаются.
По поводу показаний диспетчера задач.
Включена ли в "рабочий набор" память занятая разделяемыми(системными) библиотеками?
По поводу .NET
Какова стратегия резервирования памяти средой CLR?
Одно и то же .NET приложение при различной "степени дефицитности" памяти в системе может занимать от 1 до 30Мб(по показаниям диспетчера задач). Эта память действительно освобождается, или просто сбрасывается в своп, при дефиците физической памяти?
Здравствуйте, v.a.v, Вы писали:
VAV>Здравствуйте, Jolly Roger, Вы писали:
VAV>По поводу показаний диспетчера задач. VAV>Включена ли в "рабочий набор" память занятая разделяемыми(системными) библиотеками?
Рабочий набор — вообще "тонкая штучка, вещь в себе" Её размер слабо связан с выделением и освобождением памяти приложением, управляет им специальный системный поток, working set manager. По факту (и насколько я понимаю), это набор страниц физической памяти (не виртуальной!) Воздействие на неё со стороны приложения ограничено функцией SetProcessWorkingSetSize, но пользоваться ей без точного понимания не следует, стратегия менеджера удовлетворительна для подавляющего большинства приложений. Разумеется, сюда входят и страницы с разделяемыми библиотеками, точнее с теми их частями которые на данный момент лежат в физ. памяти.
VAV>По поводу .NET VAV>Какова стратегия резервирования памяти средой CLR? VAV>Одно и то же .NET приложение при различной "степени дефицитности" памяти в системе может занимать от 1 до 30Мб(по показаниям диспетчера задач).
Это детали реализации, не столь и существенные с точки зрения прикладного кода, откровенно говоря. Важно то, что он по факту использует "разумно жадную" стратегию, защищая приложение от голода Ведь память покупается для того, чтобы её использовать, а не "шоб було"
VAV>Эта память действительно освобождается, или просто сбрасывается в своп, при дефиците физической памяти?
И это не суть важно с точки зрения приложения. Куда важнее, чтобы он быстро управлялся со своими внутренними данными, максимально быстро реагируя на запросы приложения. И с этой точки зрения чем больше у него взятой у системы памяти, тем лучше. Но конечно, и разумных границ никто не отменял, но он за них и не выходит, по моим наблюдениям.
А сброс в своп зависит не только и не столько от размера выделенной памяти, сколько от размера реально использованной. Если страница не была модифицирована, то никто её записывать на диск не станет, зачем? Но это епархия системного менеджера. Да она и на физ. страницу-то не будет отображена, пока к ней не будет реального обращения.
VAV>Буду читать Рихтера.
Здравствуйте, Jolly Roger, Вы писали:
JR>Да она и на физ. страницу-то не будет отображена, пока к ней не будет реального обращения.
Спасибо, не знал. Но почему же тогда зарезервированная CLR память(и по большей части не использованная), входит в рабочий набор(по показаниям диспетчера задач)? Ведь рабочий набор это физическая память.
Что означают оценки "+1", "1", "2", "3"? На что они влияют?
Здравствуйте, v.a.v, Вы писали:
VAV>Здравствуйте, Jolly Roger, Вы писали:
JR>>Да она и на физ. страницу-то не будет отображена, пока к ней не будет реального обращения. VAV>Спасибо, не знал. Но почему же тогда зарезервированная CLR память(и по большей части не использованная), входит в рабочий набор(по показаниям диспетчера задач)? Ведь рабочий набор это физическая память.
А как Вы это определили? Working Set формируется системным менеджером, исходя из собственных алгоритмов, главная цель которого — облегчить жизнь приложению. Насколько я могу судить, в нём есть и страницы, которые не были ни запрошены, ни использованы приложением. Можете проделать "фокус" — запустите приложение, чтобы оно выполнило какую-нибудь ресурсоёмкую операцию и засеките размер Working Set. Теперь сверните все окна приложения и опять засеките размер. Теперь опять разверните.
VAV>Что означают оценки "+1", "1", "2", "3"? На что они влияют?
Здравствуйте, Flammable, Вы писали:
F>Создаю StreamReader, читаю им последовательно несколько файлов размером 10-80 МБ. Когда все прочитано, вызываю метод StreamREader.Close(), но никаких изменений в объеме выделенной памяти не происходит. Из каждого файла извлекается по единственной строке длиной ~30 символов. В результате такой обработки объем выделенной памяти подскакивает с 40 до 60 МБ. Даже 40 МБ меня пугают, не говоря уже о 60. F>Подскажите, как сократить объем выделяемой памяти? Есть какие-то методы оптимизации, принудительной сборки мусора?
Код покажите.
Может вы там еще какие-нибудь хештаблицы создаете, которые подгружают кучу левых дллок в память
JR>А как Вы это определили? Working Set формируется системным менеджером, исходя из собственных алгоритмов, главная цель которого — облегчить жизнь приложению. Насколько я могу судить, в нём есть и страницы, которые не были ни запрошены, ни использованы приложением.
То есть система может "дарить" процессу страницы физической памяти даже если он их не просил?
Или действует логика:"Если попросит, я(система) смогу их быстро предоставить." То есть система не "дарит" память а просто готовит ее к выдаче по будущим запросам. Так? Тогда размер Working Set действительно ничего не говорит о реальной "прожорливости" процесса.
JR>Можете проделать "фокус" — запустите приложение, чтобы оно выполнило какую-нибудь ресурсоёмкую операцию и засеките размер Working Set. Теперь сверните все окна приложения и опять засеките размер. Теперь опять разверните.
Да и без ресурсоемких операций Working Set уменьшается при сворачивании и увеличивается при разворачивании. Можно подумать что работает логика: "Окно приложения активно, процессу вскорости может потребоваться память. Подготовлю память заранее." Но почему тогда при перемещении окна на задний/передний план эта логика не работает(не видно изменений размера рабочего набора)?
Это недокументированные особенности реализации, которые, к тому-же, могут и меняться в разных версиях, потому я могу опираться тут только на свои наблюдения и логику.
Страница из виртуальной в физическую превращается при возникновении ошибки доступа. Если-бы на каждую ошибку при работе, например, с мегабайтным массивом пришлось "кланяться" Working Set Manager'у, то это было-бы весьма накладно. Вполне логично будет передавать процессу сразу много страниц, исходя из текущего положения дел с физ.памятью и даже опираясь на некоторую эвристику. Ну и при освобождении вызовом VirtualFree страницы не изымаются сразу из Process Working Set, что тоже вполне логично — они могут тут-же потребоваться снова, и при наличии резерва зачем делать лишние движения?
Сворачивание окон, видимо, принято за сигнал об окончании активной деятельности приложения, и коль система не занята, то почему-бы не заняться перераспределением физ. памяти?
Но точно знают, конечно, только разработчики. Однако отсутсвие жесткой связи между Working Set и размером аллокированной (а тем более — реально использованной) памяти — вещь совершенно очевидная.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, Don Reba, Вы писали:
JR>>>Если не хочется углубляться в механизмы, то можно принять за аксиому, что управление памятью в Windows писали отнюдь не ламеры. NET'овскую надстройку, я думаю, тоже.
DR>>Только, далеко не факт, что ценности этих не-ламеров совпадают с вашими.
JR>Ну с моими-то совпадают Тут дело такое, я подобных обсуждений видел множество, и заканчивались они всегда одним из двух вариантов. Либо автор читал что-нибудь по теме, и вопрос снимался, либо автор разбираться не желал, и уходил со стойким убеждением, что "винда маздай"
JR>Ну а в данной ветке особо-то и говорить не о чем, так как ТС так и не сообщил, откуда он берёт озвученные величины. А почти всегда в таких случаях за источник выбирают те показания из диспетчера, которые к реально занятой процессом памяти имеют наименьшее отношение, такая уж традиция сложилась И причина этому, видимо, всё та-же: у тех, кто знаком с механизмами хотя-бы в общих чертах, подобных вопросов не возникает, а те, кто не знаком, почему-то даже справку диспетчера читать не хотят
Справку я читал, правда давно В общем, StreamReader.Close() все-таки делает свое дело. Частный рабочий набор с его использованием — 22МБ, без него — 37МБ. Хотя 22МБ тоже толстовато.
Здравствуйте, Flammable, Вы писали:
F>Справку я читал, правда давно В общем, StreamReader.Close() все-таки делает свое дело. Частный рабочий набор с его использованием — 22МБ, без него — 37МБ. Хотя 22МБ тоже толстовато.
Вытащите гигабайт-другой ОЗУ из компьютера и посмотрите сколько будет показывать.
Здравствуйте, Jolly Roger, Вы писали:
JR> Ну и при освобождении вызовом VirtualFree страницы не изымаются сразу из Process Working Set, что тоже вполне логично — они могут тут-же потребоваться снова, и при наличии резерва зачем делать лишние движения?
Это не так. Винда (по крайней мере серверная) сертифицирована по стандарту безопасности С2, который среди всего прочего требует, чтобы ядро ОС всегда обнуляло страницы перед передачей их приложению. Об этом кстати у Рихтера написано.
Здравствуйте, koandrew, Вы писали:
K>Это не так. Винда (по крайней мере серверная) сертифицирована по стандарту безопасности С2, который среди всего прочего требует, чтобы ядро ОС всегда обнуляло страницы перед передачей их приложению. Об этом кстати у Рихтера написано.
Да, С2 требует. Но если я правильно помню, прямой корелляции между освобождённой памятью и изменением рабочего набора я не заметил. То есть механизм, видимо, действует несколько сложнее. Впрочем, так как это было не вчера, то есть вероятность, что память меня таки подводит В любом случае, каждый желающий всегда может поставить экспиремент самостоятельно.
остаётся один единственный вариант — некий хитрый Stream, передающийся в СтримРидер. Ну или откровенный бред автора 
"Нормальные герои всегда идут в обход!"
