Re[20]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.05.06 09:38
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Максимизировали


PD>http://www.rsdn.ru/File/187/m3.JPG


Вот о том и речь. После востановаления фокуса твоя мазила сразу отожрала 10 метров памяти, а не 1 метр как ты писал. Сравни это с тем что происходит в дотнетом приложении когда с 60 объем ворксета падает до 5 при наличии фокуса.

ЗЫ

Ктстати, сохранять скриншоты в jpeg так же неразумно как жалеть неиспользуемую памть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Память и .Net
От: Аноним  
Дата: 28.04.06 10:21
Оценка:
Интересный топик, видно основные проблемы нынешних IT.
Даже боюсь предложить изучать СУ(Р)БД.
P.s. Р в скобках, поскоку других не знаю http://www.gotdotnet.ru/Communities/Common/Images/Emoticons/BigSmile.gif
Против глупости сами боги бороться бессильны.


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re[10]: Память и .Net
От: Аноним  
Дата: 28.04.06 14:23
Оценка:
Отличный топик получился! Не поленился — прочитал все!

1. Спасибо за то, что хорошо подискутировали на тему памяти — многое для себя устаканил в голове.

2. Собственно по проблеме грида: в упор не понял зачем целиком грузить в память весь список, если в гриде видны несколько (десятков) строк. Это примерно тоже самое, что и пытаться прорисовать ВЕСЬ список, хотя он не влезает на экран.

Вот сколько разных гридов я ни использовал и какие только сумасшедшие объемы через них ни проходили, но всегда проблема памяти не стояла — в памяти были только текущие записи + кэш, который содержал следующую страницу и\или первую\последнюю для быстрой реакции на Home\End.

Вообще не представляю кому пришла в голову идея грузить все — решение же очевидно...

Всем спасибо — было интересно


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Память и .Net
От: alexeiz  
Дата: 05.05.06 03:18
Оценка: 102 (9)
#Имя: FAQ.dotnet.memoryuse
По ходу этой дискуссии видно, что не все представляют, что находится в памяти .NET процессов. Из этого проистекают всякие разные домыслы и предположения, которые по большей части не имеют отношения к действительности. Поэтому я попытаюсь очень кратко показать, как посмотреть в память .NET процесса и определить, зачем она используется и по возможности, как её можно уменьшить.

Для примера я возьму уже обсуждавшееся приложение, в котором создаётся grid и заполняется 10000 строками данных. В моём случае я его ещё дополнил кнопкой "GC.Collect", чтобы вызывать сборку мусора, когда необходимо для тестовых целей. Визуально это выглядит вот так:

http://rsdn.org/File/15955/wstest.PNG

Код для приложения элементарен и выглядит так:
            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:
Category                        Total        Private Shareable    Shared
                           Pages    KBytes    KBytes    KBytes    KBytes
      Page Table Pages        40       160       160         0         0
      Other System            14        56        56         0         0
      Code/StaticData       2105      8420       540      2564      5316
      Heap                   214       856       856         0         0
      Stack                   16        64        64         0         0
      Teb                      4        16        16         0         0
      Mapped Data            121       484         0        28       456
      Other Data            2072      8288      8284         4         0

      Total Modules         2105      8420       540      2564      5316
      Total Dynamic Data    2427      9708      9220        32       456
      Total System            54       216       216         0         0
Grand Total Working Set     4586     18344      9976      2596      5772

Module Working Set Contributions in pages
    Total   Private Shareable    Shared Module
        5         2         3         0 wstest.exe
       58         3         0        55 ntdll.dll
       20         2         0        18 mscoree.dll
       48         3         0        45 KERNEL32.dll
       17         1         0        16 ADVAPI32.dll
       13         1         1        11 RPCRT4.dll
       31         2         0        29 SHLWAPI.dll
       34         2         1        31 GDI32.dll
       48         2         0        46 USER32.dll
       38         4         0        34 msvcrt.dll
       12         2         0        10 IMM32.DLL
        8         2         0         6 LPK.DLL
       36         6         0        30 USP10.dll
      257        14        21       222 mscorwks.dll
       53         6         1        46 MSVCR80.dll
       38         8         0        30 shell32.dll
       44         2         0        42 comctl32.dll
       17         4         0        13 comctl32.dll
      288        13        35       240 mscorlib.ni.dll
       32         4         0        28 ole32.dll
       25         2         0        23 uxtheme.dll
       21         3         0        18 MSCTF.dll
       30         4         0        26 DpOFeedb.dll
       69         2         0        67 mscorjit.dll
       67         6        15        46 System.ni.dll
       83         7        54        22 System.Drawing.ni.dll
      561        17       445        99 System.Windows.Forms.ni.dll
      125         7        62        56 gdiplus.dll
       22         2         0        20 msctfime.ime
        5         2         3         0 dciman32.dll

Необходимо отметить, что цифры Process Explorer’а и vadump’а немного отличаются, потому что они получены при разных запусках приложения.

Начнём анализировать. За код и статические данные отвечает следующая строчка:
Category                        Total        Private Shareable    Shared
      Code/StaticData       2105      8420       540      2564      5316

Она представляет из себя сумму по всем модулям процесса. Всего 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 занят живыми объектами. Какая-то его часть свободна. Это можно узнать, пройдя по всем объектам в хипе:
0:004> !dumpheap -stat
total 232157 objects
Statistics:
      MT    Count    TotalSize Class Name
7b4c3800        1           12 System.Windows.Forms.DataGridViewColumnCollection+ColumnOrderComparer
7b47ef7c        1           12 System.Windows.Forms.SR
…
7b46d674    40543       648688 System.Windows.Forms.PropertyStore
7b4c7f0c    30006       960192 System.Windows.Forms.DataGridViewTextBoxCell
7b49bf58    30176       967352 System.Windows.Forms.PropertyStore+IntegerEntry[]
7b49c090    30260       973380 System.Windows.Forms.PropertyStore+ObjectEntry[]
00152a70    16158      1291624      Free
790fa3e0    36516      1829392 System.String
Total 232157 objects

Теперь понятно, что свободно у нас около 1.3MB. Это та память, которую GC может в принципе отдать OS, но он этого не сделает, потому как по сравнению с полным размером GC Heap (8.4MB) это очень мало. Для compacting GC нормально иметь вдвое больше памяти, чем требуется для живых объектов.
Re[21]: Память и .Net
От: ie Россия http://ziez.blogspot.com/
Дата: 05.05.06 03:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ктстати, сохранять скриншоты в jpeg так же неразумно как жалеть неиспользуемую памть.


А почему?!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[17]: Память и .Net
От: ie Россия http://ziez.blogspot.com/
Дата: 05.05.06 03:43
Оценка: -1
Здравствуйте, alexeiz, Вы писали:

A>OK. Видно, что vadump нам не соврал. Действительно GC heap в данный момент отнимает ~8.4MB памяти. Однако, не весь GC Heap занят живыми объектами. Какая-то его часть свободна. Это можно узнать, пройдя по всем объектам в хипе:

A>
A>0:004> !dumpheap -stat
A>total 232157 objects
A>Statistics:
A>      MT    Count    TotalSize Class Name
A>7b4c3800        1           12 System.Windows.Forms.DataGridViewColumnCollection+ColumnOrderComparer
A>7b47ef7c        1           12 System.Windows.Forms.SR
A>…
A>7b46d674    40543       648688 System.Windows.Forms.PropertyStore
A>7b4c7f0c    30006       960192 System.Windows.Forms.DataGridViewTextBoxCell
A>7b49bf58    30176       967352 System.Windows.Forms.PropertyStore+IntegerEntry[]
A>7b49c090    30260       973380 System.Windows.Forms.PropertyStore+ObjectEntry[]
A>00152a70    16158      1291624      Free
A>790fa3e0    36516      1829392 System.String
A>Total 232157 objects
A>

A>Теперь понятно, что свободно у нас около 1.3MB. Это та память, которую GC может в принципе отдать OS, но он этого не сделает, потому как по сравнению с полным размером GC Heap (8.4MB) это очень мало. Для compacting GC нормально иметь вдвое больше памяти, чем требуется для живых объектов.

Меня больше привлек такой момент: Free + System.String = 3121016 — что как раз таки показывает прожорливость System.Windows.Forms, а отнюдь не прожорливость GC.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[22]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.05.06 05:04
Оценка: +1
Здравствуйте, ie, Вы писали:

Потому что они при этом получаются хренового качества, не выигрывают в размерах и не пригодны для какй-бы то нибыло дальнейшей обработки.
Скриншоты нужно записывать в GIF (если цветов мало, до 255) или в png.

В jpeg же имеет смысл записывать только фотографии и многоцветные картинки. Вот тут jpeg дает и оптимальное сжатие, и jpeg-артефакты мешают не особо сильно. Правда и тут нужно умудриться не переборщить со степенью сжатия, так как на максимальных степенях jpeg способен угробить любую фотогнафию.

В общем-то это очеведные вещи и любой кто задумается над сутью вопроса может прийти к выводам сам, но почему-то большинство людей упорно не хотят думать и раз за разом наступают на те же грабли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Память и .Net
От: ie Россия http://ziez.blogspot.com/
Дата: 05.05.06 05:17
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

VD>В общем-то это очеведные вещи и любой кто задумается над сутью вопроса может прийти к выводам сам, но почему-то большинство людей упорно не хотят думать и раз за разом наступают на те же грабли.


Ужас!
... << 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 они всегда всем свинью подкладывают
и еще раз повторюсь сделайте из топика статью на сайте хотя бы для озанкомления очень хорошо
Re[17]: Память и .Net
От: Блудов Павел Россия  
Дата: 05.05.06 05:37
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

A>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).


А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?
http://gzip.rsdn.org/File/507/procexpscreen.PNG
... << RSDN@Home 1.2.0 alpha rev. 642>>
Re[18]: Память и .Net
От: alexeiz  
Дата: 05.05.06 06:12
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

БП>Здравствуйте, alexeiz, Вы писали:


A>>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).


БП>А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?


Я привел всего лишь один пример применения SOS. SOS может использоваться для отладки очень многих вещей в .NET.

Process Explorer берет информацию из performance counter'ов.
Re[18]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.05.06 06:30
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

A>>Дальше нужно двигаться с помощью windbg и модуля для отладки .NET процессов sos.dll (сокращённо от Son of Strike, в версии 1.0 этот модуль назывался strike).


БП>А чем не устраивают цифры с закладки .Net в свойствах процесса в упомянутом раньше ProcExp'е?

Согласен, но alexeiz правильно указал, что SoS позволяет разобраться в том на что тратится память более детально.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.05.06 06:30
Оценка:
Здравствуйте, alexeiz, Вы писали:

Хороший анализ и вообще достойное сообщение. Надо его будет в ФАК засунуть.

Однако кое-что ты все таки не учитывашь. Так что добавлю пару слов.

A>Теперь приступим к анализу памяти (working set), требуемого этим приложением. Для начала посмотрим, что нам говорит Process Explorer (sysinternals.com): Working Set: 18896KB, Private Bytes: 20300KB.


Вот первое на что ты не обратил внимание, а стоило бы.
Практически аналогичный тест на моей рабочей машине привел к тому, что верксет и виртуалка процесса разраслась до ~60 МБ.
На моем ноутбуке этот же тес привел к разростанию ворксета до ~35 МБ в когда в системе было еще много памяти и к 15 когда я загрузил по больше процессов.

По уму конечно надо бы поглядеть рассклад по подробнее, но и так видна общая зависимость. Если в ОС есть много свободной памяти, управляемый процесс использует ее более активно.

Кстати, на основании того, что процесс занял всего 18 МБ можно предположить, что на твоей машине объем памяти составляет что-то около 500 метров. Я угадал?

Таким образом рассуждения о том кто занимает память явно зависят от машины на которой проводятся эксперементы, а стало быть делать выводы нужно куда как осторожнее.

A>
A>0:004> !dumpheap -stat
A>total 232157 objects
A>Statistics:
A>      MT    Count    TotalSize Class Name
A>7b4c3800        1           12 System.Windows.Forms.DataGridViewColumnCollection+ColumnOrderComparer
A>7b47ef7c        1           12 System.Windows.Forms.SR
A>…
A>7b46d674    40543       648688 System.Windows.Forms.PropertyStore
A>7b4c7f0c    30006       960192 System.Windows.Forms.DataGridViewTextBoxCell
A>7b49bf58    30176       967352 System.Windows.Forms.PropertyStore+IntegerEntry[]
A>7b49c090    30260       973380 System.Windows.Forms.PropertyStore+ObjectEntry[]
A>00152a70    16158      1291624      Free
A>790fa3e0    36516      1829392 System.String
A>Total 232157 objects
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>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.05.06 06:33
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Я привел всего лишь один пример применения SOS. SOS может использоваться для отладки очень многих вещей в .NET.


+1

A>Process Explorer берет информацию из performance counter'ов.


И тем неменее она куда как удобнее если нужно поглядеть информацию о кучах в целом и статистику сборок мусора. А SoS больше полезен для выявления того куда тратится память.

Добавлю сюда же, что для этих целей так же очень удобно использовать Memory Profiler. Он дает очень интересную статистику.
... << RSDN@Home 1.2.0 alpha rev. 637>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Память и .Net
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 05.05.06 09:01
Оценка: 2 (1) +3
Здравствуйте, ie, Вы писали:

ie>А почему?!

Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше таких резких переходов — тем ниже коэффициент сжатия и тем хуже конечный результат. Хуже всего — черный текст на белом фоне.
GIF оптимизирован под большие площади, залитые одинаковым цветом, а также под изображения с малым количеством использованных цветов.
Большинство скриншотов используют относительно мало цветов, и относительно много текста/рамочек. Поэтому применение JPEG для них — симптом абсолютного непонимания автором цифровых форматов изображений.
З.Ы. Естественно, сие не догма. Если скриншот должен продемонстировать как раз существенно полутоновые особенности — типа градиентов в заголовках или полупрозрачности окошек — то, конечно, жпег велкам.
http://rsdn.org/File/5743/rsdn@home2.gif 1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: Память и .Net
От: mrozov  
Дата: 05.05.06 10:09
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin,

Просто результат наблюдений.

Как я понял из дальнейшего обсуждения, ты последовательно игнорируешь все рассуждения опонентов про GC, мотивируя это тем, что чудес не бывает и .net от с++ для win ничем не отличается — перед богом все равны.

Ок.

Допустим, я напишу программу (на чистом c++, разумеется), которая при запуске (и далее по таймеру в 30 секунд) делает одну простую вещь — отжирает ровно 10% от имеющейся свободной памяти. Если выясняется, что программа уже отожрала больше 10% оной — она ее освобождает.
Далее, мы запускаем эту чудо-программу (must have) на машине с гигом свободной памяти — и видим, что она отожрала 100 Мб!!!
Нетрудно подсчитать, что система сможет одновременно выдержать не больше 10 экземпляров оной. Не удивительно, что программы на c++ теряют популярность — при такой-то прожорливости.

Подтвердим теорию практикой — запустим второй экземпляр. Однако он почему-то занял только 90 Мб — странно. Проверив через какое-то время первый экземпляр обнаруживаем, что он теперь занимает 81 Мб — вообще мистика!
А запустив 100 экземпляров получаем (после того, как устаканится своп ) вполне работоспособную систему. Выходит, что с++ не так уж и плох! (В моем примере все 100 экземпляров будут постоянно циклически перестраивать занимаемый собой объем памяти, но это издержки наглядности)

Что мы имеем? Мы имеем систему, которая на первый взгляд кажется черезвычайно прожорливой, а на самом деле — это только фикция. Т.е. модель .net-а.

Я думаю, что теперь настало самое время вернуться к рассмотрению вопроса о том, нафига .net ведет себя таким образом — но это тебе на разные лады повторяли уже раз тридцать по меньшей мере — для эффективности и экономии ресурсов машины.

Ага?
Re[23]: Память и .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.05.06 10:43
Оценка:
Здравствуйте, 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>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Память и .Net
От: _d_m_  
Дата: 05.05.06 10:47
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ie, Вы писали:


ie>>А почему?!

S>Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше

Он не "основан на предположении о том", а просто лучше подходит для таких случаев. А как и все алгоритмы сжатия с потерями основан на том что: любую ф-цию (даже и произвольную кривую и прямоугольные колебания) можно представить набором синусоид (гармоник). И чем больше степень сжатия, тем больше высших гармоник мы убираем, тем грубее приближение полученой суперпозиции оставшихся гармоник. Резкие границы как-раз представляют пример прямоугольного колебания, а в этом случае для более точного приближения результирующей кривой к исходной необходимы как раз высшие гармоники.
Для интересующихся см. раздел высшей математики "Ряды Фурье". Раздел этот появился еще задолго до jpeg-ов и алгоритмов сжатия, в 18 веке вроде.
Re[8]: Память и .Net
От: Pavel Dvorkin Россия  
Дата: 05.05.06 11:20
Оценка: :))
Здравствуйте, 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>Ага?


Почитай книги по функционированию ОС и системных механизмах.
With best regards
Pavel Dvorkin
Re[9]: Память и .Net
От: mrozov  
Дата: 05.05.06 11:43
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Почитай книги по функционированию ОС и системных механизмах.


Ты хочешь сказать, что я не смогу написать программу, которая принудительно захватит 100МБ? И освободит половину по мере надобности?

Если я тебя правильно понял, то могу порекомендовать тебе почитать вообще хоть что-нибудь, кроме книг по программированию, а еще лучше — съездить в отпуск, погреть кости на солнышке.

Павел, я тебе описал поведение программы, которое было внесено сознательно. Давай двигаться маленькими шажками.

— Пойдем логическим путем.
— Пойдем вместе.


Веришь ли ты в существование программы, которая выделит себе память... скажем в виде массива цифр от 0 до 10 количеством в 100МБ?
Веришь ли ты в существование программы, которая в какой-то момент (скажем по таймеру) освободит половину этой памяти?

Если нет — ну... может мне и в самом деле стоит освежить свои знания ОС... да и вообще сменить профессию.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.