Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
Здравствуйте, _Artem_, Вы писали:
_A_>Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
Чтото маловато... Как добились?
[RSDN@Home][1.2.0][alpha][648]
[Одно и то же слово и совет Hа пользу мудрецу, глупцу во вред. [аль-Хусри]]
Hello, "_Artem_" > > И вообще нормально ли что .Net столько отъедает?
А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать
то, что сборка мусора выполняется в моменты когда это необходимо. Кроме
этого, надо учитывать то, как именно считается объем занимаемой памяти.
Значение в 40Mb совершенно не означает, что это именно физическая память.
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, _Artem_, Вы писали:
_A_>Здраствуйте форумчане!
_A_>Решили мы переходить на .Net и начало смущать одно обстоятельство: Форма с гридом и начитанными в него данными из таблицы с 10000 записями занимает в памяти около 40 мб. Можно ли уменьшить количество памяти, занимаемое приложением? И вообще нормально ли что .Net столько отъедает?
.Net сьедает сколько ему "позволят". Куда ушли 40 МБ можно посмотреть например при помощи CLRprofiler или SOS.DLL + debugger
Здравствуйте, 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 столько отъедает?
Здравствуйте, 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>ВыньФормс-приложение с 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 это будут жутко тормозить
Здравствуйте, VladD2, Вы писали:
VD>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти, то выньте из машины лишний гигабайт оперативки и наслаждайтесь малыми показателями в купе с тормозами. А лучше найдите хорошего психотерапевта. Может он убедит вас в том, что времена сейчас не досовские, памяти много и глупо не использовать ее для оптимизации работы приложения.
Да уж, замечательно.
Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем.
Имхо, психологические проюлемы у тех, кто не понимает что в некоторых ситуациях, это дело может действительно тормозить.
Не всегда на машине по гигу памяти.
Здравствуйте, <Аноним>, Вы писали: А>Да уж, замечательно. А>Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем. А>Имхо, психологические проюлемы у тех, кто не понимает что в некоторых ситуациях, это дело может действительно тормозить. А>Не всегда на машине по гигу памяти.
Очень рекомендую все-таки натравить на приложение дотнет мем-профайлер и посмотреть, что и куда уходит. Оценить реальные расходы памяти. Прикинуть, как это будет себя вести на системах с меньшим количеством 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
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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% примерно съела.
Здравствуйте, 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
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>Слушай, ну не надо. Возьми Соломона — Руссиновича, "Внутреннее устройство 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
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
1.1.4 stable rev. 510
