Каморка

какой функцией в С# посмотреть сколько памяти отведено aspnet_wp.exe?
и чтобы цифра совпала с таск манагером - колонка memory usage.

А то GC и Process показывают цифры не совпадающие с таск манагером ( колонка memory usage).

Что вы делаете чтобы уменьшить скачки в показаниях от GC.GetTotalMemory()?
-часто используемые объекты засунуть в сессию
-чистить коллекции после использования
-вызывать Dispose усли есть
-делать имяПеременной = null после использования
-...(дописать свое)

Как уменьшить memory usage в таск манагере я знаю. Но это лапшистый способ для манагеров и клиентов.
А вот хочется для души - шоб реально меньше было.

Мармот - ты хотел поговорить за программирование.

polkov писал(а):Мармот - ты хотел поговорить за программирование.

Паспорт знает за подполье

polkov писал(а):какой функцией в С# посмотреть сколько памяти отведено aspnet_wp.exe?
и чтобы цифра совпала с таск манагером - колонка memory usage.

А то GC и Process показывают цифры не совпадающие с таск манагером ( колонка memory usage).

Что вы делаете чтобы уменьшить скачки в показаниях от GC.GetTotalMemory()?
-часто используемые объекты засунуть в сессию
-чистить коллекции после использования
-вызывать Dispose усли есть
-делать имяПеременной = null после использования
-...(дописать свое)

Как уменьшить memory usage в таск манагере я знаю. Но это лапшистый способ для манагеров и клиентов.
А вот хочется для души - шоб реально меньше было.

Мармот - ты хотел поговорить за программирование.

Я за винду и С# ничего сказать не могу, но за Java/Linux можно побазарить.
У мня как раз сейчас экономия памяти одна из главных задач...
имяПеременной = null зависит от того где переменная, на стеке или это поле объекта
Если поле объекта, то делать надо, Dispose тоже лучше сделать, если есть...
Коллекции надо чистить тоже только если остаются reachable
A вообще надо стремится созадавать как можно меньше мусора, особенно больших буферов, меньше потоков, etc.
Не знаю как в .Net, но в JVM можно сбросить heap dump и посмотреть, где чего, сколько и почему...
Очень полезный инструмент...

Marmot писал(а): Я за винду и С# ничего сказать не могу, но за Java/Linux можно побазарить.
У мня как раз сейчас экономия памяти одна из главных задач...
имяПеременной = null зависит от того где переменная, на стеке или это поле объекта
Если поле объекта, то делать надо, Dispose тоже лучше сделать, если есть...
Коллекции надо чистить тоже только если остаются reachable
A вообще надо стремится созадавать как можно меньше мусора, особенно больших буферов, меньше потоков, etc.
Не знаю как в .Net, но в JVM можно сбросить heap dump и посмотреть, где чего, сколько и почему...
Очень полезный инструмент...

Ну давай за жабу - надеюсь шо подходы общие.
Ты перечислил тоже самое что и в моем списке. А добавить из своего опыта?
Из простых вещей - имею в виду без разговоров о редизайне и пр.

Кста - не знаю как в жабе - но C# лучше поменьше использовать проперти (это те которые Get-Set) если они действительно не несут доп.логики. Память кушать любят.

Еще мне не понравилась фигня типа
ИмяКласса переменная = (ИмяКласса)Session["переменная"]
В моем случае отжирает по 300кб.
Пришлось завести член класса и заменить локальные переменные.

И еще, про таск манагер, что он там декйтвительно показывает надо смотреть в его сорцах, чем мне нравится Linux, так это тем, что всегда в конце концов можно посмотреть сорцы и понять, что там происходит Ну, конечно если очень сильно надо. Но, например в сорсы JVM я заглядываю регулярно, просто что бы понять как правильно оптимизироваться...

polkov писал(а):

Marmot писал(а): Я за винду и С# ничего сказать не могу, но за Java/Linux можно побазарить.
У мня как раз сейчас экономия памяти одна из главных задач...
имяПеременной = null зависит от того где переменная, на стеке или это поле объекта
Если поле объекта, то делать надо, Dispose тоже лучше сделать, если есть...
Коллекции надо чистить тоже только если остаются reachable
A вообще надо стремится созадавать как можно меньше мусора, особенно больших буферов, меньше потоков, etc.
Не знаю как в .Net, но в JVM можно сбросить heap dump и посмотреть, где чего, сколько и почему...
Очень полезный инструмент...

Ну давай за жабу - надеюсь шо подходы общие.
Ты перечислил тоже самое что и в моем списке. А добавить из своего опыта?
Из простых вещей - имею в виду без разговоров о редизайне и пр.

Кста - не знаю как в жабе - но C# лучше поменьше использовать проперти (это те которые Get-Set) если они действительно не несут доп.логики. Память кушать любят.

Еще мне не понравилась фигня типа
ИмяКласса переменная = (ИмяКласса)Session["переменная"]
В моем случае отжирает по 300кб.
Пришлось завести член класса и заменить локальные переменные.

Хорошая штука lazy initalization, часто бывает что какая-нибудь коллекция используется не всеми экземплярами класса, тогда ее можно сделать null в конструкторе и инициализировать только когда она действительно нужна.
Или можно ее инициализировать с начальным размером ноль. Часто у коллекций дефолтный начальный размер может быть 16 или даже 32.
Про проперти я не копенгаген, их у нас нет
В случае сессий мне непонятно, объекты туда сериализиются, что ли? почему так много? 300К это для одного объекта?
А вообще все это сильно framework dependent...

Marmot писал(а): В случае сессий мне непонятно, объекты туда сериализиются, что ли? почему так много? 300К это для одного объекта?
А вообще все это сильно framework dependent...

Хороший вопрос про сериализацию - надо прочитать про. А то просто заметил и сделал воркэраунд. А о вечном подумать совсем нет времени

А вот кстати о XML - ты чего пользуешь если не надо изменять?
XmlDocument or XmlPathDocument? если подобное есть в жабе.

И еще о XSLT - насколько оно прожорливо?
У нас почти все веб странички формируются в рантайме.

polkov писал(а): А вот кстати о XML - ты чего пользуешь если не надо изменять?
XmlDocument or XmlPathDocument? если подобное есть в жабе.

И еще о XSLT - насколько оно прожорливо?
У нас почти все веб странички формируются в рантайме.

Я последнее время использую исключительно StAX parser(до этого SAX), построение любых обобщенных объектных моделей (в том числе для XSLT) требует туеву хучу памяти и тормозит неподецки. Мне проще (и раз в 10-100 эффективнее) самому сделать все преобразования и построение моих собственных оптимизированных объектов.
Т.е. с точки зрения производительности и использования памяти DOM/XSLT это абсолютное зло!

XmlDocument грузится полностью в память, потом с ним можно работать. Лучше использовать потоки, типа XmlReader или другие классы. Сейчас есть из чего выбирать. XmlDocument - зло для больших Xml файлов. 10К файл легко превращается в 100К, а то и в 1000К в памяти.
Вместо XmlSerializer лучше использовать DataContractSerializer. Он попроще, но значительно быстрее и с памятью значительн лучше работает: http://msdn.microsoft.com/en-us/library/ms731073.aspx
Если внутри Xml надо только парочку данных выбрать, можно тупо RegEx использовать.
Вообще, лучше освоить по-хорошему Stream-ы, в плане памяти сильно помогает.

Кстати Linq тоже lazy инициализацию использует хорошо. Linq.Xml вообще очень хорош.

А вот еще Rx (http://msdn.microsoft.com/en-ca/devlabs/ee794896.aspx) "реактивное расширение". Во многих местах кучу кода на несколько строк меняет. При этом все дико упрощает (но перед этим надо соображалку на другие рельсы повернуть).

Потом ламбды тоже сильно код сокращают, опять же двигают его в lazy инициализацию.

Но все же лучше всего помогает хорошая алгоритмическая подготовка. Если понимаешь, как и почему, то проще решения принимать на начальных этапах. Меньше былко-кода получается.

Leo Gan писал(а):XmlDocument грузится полностью в память, потом с ним можно работать. Лучше использовать потоки, типа XmlReader или другие классы. Сейчас есть из чего выбирать. XmlDocument - зло для больших Xml файлов. 10К файл легко превращается в 100К, а то и в 1000К в памяти.

Ага - спасибо.
А что скажешь за XSLT? XML преобразуется в ASP.NET и выдается клиенту.
Какие классы лучше использовать?
Хотя думается что парсинг Page.ParseControl тоже отьедает немаленький кусок памяти

Leo Gan писал(а): Но все же лучше всего помогает хорошая алгоритмическая подготовка. Если понимаешь, как и почему, то проще решения принимать на начальных этапах. Меньше былко-кода получается.

Большие системы очень редко пишутся с нуля и одним человеком.
Я занимаюсь памятью и перформансем на 4 или 5 системе - такого насмотрелся!!!

Самое классическое из моего опыта - используют string/CString (C# or C++) для получения больших строк из маленьких кусочков

Если использовать конструкцию то вызывать Dispose() не нужно будет - зачистится аккуратненько

вот, кстати, занятный перечень:

Ten caching mistakes that break your app

polkov писал(а):Самое классическое из моего опыта - используют string/CString (C# or C++) для получения больших строк из маленьких кусочков

Как это?

Fedor P. писал(а):

polkov писал(а):Самое классическое из моего опыта - используют string/CString (C# or C++) для получения больших строк из маленьких кусочков

Как это?

string var = "kusok1"
...
var += "kusok2"
...
var += "kusok3"

Если честно, то топик получился детсадовский какой-то...
Люди, читайте доки и сорсы, а так же попытайтесь думать...