Комментарии 23
Спасибо. очень полезная, должно быть, штука.
А как вообще через код C# можно определить, какие объекты находятся в памяти?
А как вообще через код C# можно определить, какие объекты находятся в памяти?
Если почитать два последних поста от Jet, то в них можно найти видео.
В одном из которых автор доклада бегает по куче и считает объекты используя C# unsafe.
Можно использовать windbg с расширением SOS.dll, SOSEX.dll.
Запускаем программу, цепляемся в нужном месте, и смотрим SOH (0,1,2) и LOH.
В одном из которых автор доклада бегает по куче и считает объекты используя C# unsafe.
Можно использовать windbg с расширением SOS.dll, SOSEX.dll.
Запускаем программу, цепляемся в нужном месте, и смотрим SOH (0,1,2) и LOH.
Спасибо. Не могли бы привести пример, если не затруднит.
1) Человек из JetBrains.
www.youtube.com/watch?v=KbuJdkPLAjw
2) Windbg.
Если попытаться загрузить sos при старте приложения ничего не выйдет, надо аттачиться когда процесс уже прошел первичную инициализацию.
www.youtube.com/watch?v=KbuJdkPLAjw
2) Windbg.
!dumpheap [-stat] [-mt <>] [-type <>] [-strings] [-min] [-max]
(What classes take space in managed heap)
!dumpgen <genNum> [-free] [-stat] [-type <>] [-nostrings]
(Dumps the contents of the specified generation (sosex))
!dumpdomain (сколько доменов.)
!EEVersion (отображает версию GC.)
!threads (отображает потоки. -special для специальных потоков)
!dumpheap (garbage collector heap.)
!dumpheap -type SpaceName.Type (покажет объект в куче.)
!dumpheap -type Free -stat (поиск пустых объектов, показывает кол-во всего и пустые из них.)
!gcroot XXX (отображает тех кто удерживает объект от сборки.)
!objsize XXX (отображает размер объекта (и все объекты на которые он ссылается, включено в него.)
Если попытаться загрузить sos при старте приложения ничего не выйдет, надо аттачиться когда процесс уже прошел первичную инициализацию.
НЛО прилетело и опубликовало эту надпись здесь
Интересная статья, но dotMemory Unit не рекомендуют совмещать с unit тестами, потому что обычно unit тесты гоняют под конфигурацией Debug а dotMemory Unit больше любит Release конфигурацию. А еще статья расширила мой лексикон такими словами как: профиляция, профилятор :).
эмм, я так понимаю это не проблема dotMemory Unit. Просто в Debug билдах, те объекты на которые ссылается отладчик не будут собраны во время GC (даже если они уже не нужны самой программе). Собсно поэтому с точки зрения потребления памяти смотреть надо всегда на Release билды.
НЛО прилетело и опубликовало эту надпись здесь
А известно про что-нибудь подобное для C++?
Извините, но в статье-переводе я на «профиляцию» не согласен. Давайте все вместе:
память профилировали, профилировали да невыпрофилировали, надо память перепрофилировать, перевыпрофилировать
память профилировали, профилировали да невыпрофилировали, надо память перепрофилировать, перевыпрофилировать
и да, делали это профайлером
Это у них в JetBrains такой сленг. Посмотрите их доклады с .NEXT, там то же самое :).
НЛО прилетело и опубликовало эту надпись здесь
Скорее всего, правильно будет: Профилирование и профилировщик.
Как это интегрируется с CI?
Если я правильно понимаю, то на агенты построений придётся поставить ReSharper или dotCover.
Если я правильно понимаю, то на агенты построений придётся поставить ReSharper или dotCover.
Поэтому для запуска dotMemory Unit тестов, на вашей машине должен быть устанолен ReSharper 9.1 или dotCover 3.1.Перестанут ли работать тесты после завершения триала?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Можно ли совместить юнит тесты и профилирование памяти?