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

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

H>>>>>Это оверхед не аллокатора, а организации данных. Но тем не менее.
G>>>>указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.

H>>>Аллокатору нужны списки блоков? Нужны. Нужны размеры блоков? Нужны. Эти вещи, используемые любым аллокатором, считать оверхедом нельзя. Считать оверхедом можно большее, нежели было запрошено, выделение памяти, что присутствует в приведенном в качестве примера дельфийском менеджере (но учитывая эффективность пулов, этот оверхед обсуждать смешно).
G>>Еще раз, в .NETовском аллокаторе не нужны ни списке блоков, ни размеры. (размеры есть в метаданных)

H>Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении).
Вы бы разобрались что скрывается под словами "строит граф", обычный рекурсивный обход без построения динамических структур.
Оверхеда там действительно нет, как бы вам не хотелось обратного.

H>Размеры, и правда можно из метаданных получать, заплатив перформансом
С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).

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

H>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера:
H>

Как видите, сбор мусора вызывает существенное снижение производительно-
H>сти — это основной недостаток управляемой кучи.

Только это все может работать быстрее, чем аллокатор на основе списков.

G>>Я больше чем уверен что вы спокойное кешируете в памяти множество данных, получаемых извне.
H>По требованию алгоритма, но не аллокатора
А какая разница?


G>>Кстати при отсутствии необходимости создавать объекты на стеке многие С++ники часто ргугают другие языки из-за отсуствия такой возможности.
H>Ну на стеке быстрее, просто...
Не всегда, размещение объектов на стеке часто приводит к копированию этих объектов когда не надо.
Для выпрямления такой ситуации в C++ есть ссылки — безопасный, но ограниченный в возможностях аналог указателей.

G>>Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени.
H>Там есть Private bytes.
И че?


G>>>>Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков.
H>>>Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)?
G>>Нативная программа использует GDI+ для этих целей?
G>>Память там в основном жрет не .NET, а GDI+ (который тоже нативный).

H>Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается.
Меня измерения потребляемой памяти на HelloWorld не интересуют.

G>>Кроме того перечитайте еще раз мой пост о статическом оверхеде .NET, может тогда поймете почему не стоит сравнивать потребление памяти на программах типа HelloWorld
H>Это далеко не HelloWorld. Впрочем, сравнивать все равно, что. У .Net, расход на аналогичных вещах выше, такова объективная реальность.
Да как раз не все равно. Ты перечитай еще раз о чем я тебе толкую. .NET поребляет больше памяти на практически константную величину. Истории о том что кто-то запустил программу на .NET и она схавала сразу все свидетельствуют о криворукости автора программы, а не об особенностях работы с памятью в .NET.