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

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

WW>>Собственно размеры хиров, где содержатся managed обекты при этом не менются.

WW>>Теперь по вашему вопросу. Не могли бы Вы, коротенько, в паре абзацах, объяснить что именно Вы имели в виду?

_NN>Всё так. Только .NET Memory Profiler умеет показывать размеры выделенных блоков , а dotMemory нет.
_NN>Сборщик мусора конечно всё соберёт, но пиковове потребление памяти останется в истории

Добрый день

Если вы не против нам помочь, можно я вас попытаю? Пока совсем не понятно какую проблему вы решаете.

Давайте я опишу, что я понял из дискуссии, и отвечу на некоторые вопросы, а потом позадаю их сам.

Для взятия снимка памяти через MS Profiling API, dotMemory запрашивает полную сборку мусора, в идеале в графе объектов, который выдал MS Profiling API, не должно быть недостижимых объектов, так как они должны быть собраны. Но по факту, бывает, что он выдаёт некоторое кол-во объектов связанных друг с другом, но не достижимых из GC roots. Видимо, это какая-то внутренняя оптимизация или просто особенности работы GC. Эти объекты будут собраны в последующих GC. Какую пользу можно извлечь из знания какие объекты не были собраны из-за особенностей реализации сборщика мусора?

Windows memory dump можно взять в произвольный момент, то есть в момент между сборками мусора, когда часть ссылок уже потеряна логикой программы, но GC ещё не собрал недостижимые объекты. Они будут собраны в ближайший GC (с учётом сказанного в предыдущем абзаце). Здесь тоже непонятно какую проблему можно решить увидев случайный (случайный, потому что если dump взять на несколько миллисекунд раньше или позже, картина будет совершенно другая) набор уже недостижимых, но ещё не собранных объектов.

Далее вы пишете, что SkiTech "умеет показывать размеры выделенных блоков", мы имеете в виду размеры managed heaps. Это то, что dotMemory показывает на "Group By Generations" для All Objects, или что-то другое? Если другое, расскажите, пожалуйста, что именно, или дайте screenshot/ссылку из SkiTech.

И "пиковое потребление памяти останется в истории". Потребление памяти dotMemory показывает во время профилирования, на графике Timeline, и это будет настоящее потребление в каждый момент времени. Взятие dump в произвольный момент, даст некоторую оценку снизу, в силу случайности, которая описана выше.

И, собственно, вопрос. Вы можете описать, какую проблему вы решаете? Не какие данные, как вам кажется, для этого нужны, а именно техническое описание самой проблемы?

Потому что пока возникает ощущение, что вы хотите увидеть memory traffic своего приложения, и dotMemory умеет его показывать в удобном виде. Удобнее чем произвольный набор недостижимых объектов.

Спасибо!