Как определить причину бокса в .Net?

Question

Резюме

Мы должны понять, какая часть нашего (или третьей стороны, возможно, самого CLR) кода приводит к упаковке целых чисел.

Описание проблемы

У нас довольно большое приложение, где мы наблюдаем высокую скорость выделения System.Int32 экземпляров. С помощью Memory Profiler мы видим небольшое количество длинных существующих Int32 экземпляров (точнее, 18) и 20-25 тысяч Int32 выделений в секунду. Все эти объекты GC собраны как объекты Gen0, система не имеет утечек памяти и может работать в течение длительного времени. При создании моментального снимка памяти GC выполняется до моментального снимка, поэтому моментальный снимок не содержит следов этих «временных» объектов.

Весь наш код был специально написан, чтобы по возможности исключить бокс, и «по замыслу» мы должны вообще не видеть боксы. Таким образом, мы подозреваем, что это какой-то неисчерпаемый забытый бокс в нашем коде или бокс, вызванный сторонним компонентом и / или самим типом CLR.

Система скомпилирована с использованием VS2008 и использует .Net 3.5 (измерения проводились как в отладочной, так и в выпускной сборках, с одинаковым поведением).

Вопрос

Как мы можем (используя windbg, VS2008, Memory Profiler, AQTime или любой другой коммерчески доступный продукт) определить, почему происходит бокс?

Answer 1

Весьма удивительно, что методы класса DateTime ToLocalTime / ToUniversalTime вызывают бокс.

Наше приложение (сервер приложений) было недавно изменено, чтобы работать «внутри» только в UTC (чтобы справиться с изменениями в дневное время и т. Д.). Наша клиентская кодовая база осталась на 99% по местному времени.

Сервер приложений преобразует (при необходимости) локальное время в UTC перед обработкой, эффективно вызывая накладные расходы при каждой операции, связанной с временем.

Мы рассмотрим повторное выполнение этих операций "на дому", без бокса.

Answer 2

Одно из моих любимых приложений - CLR Profiler, оно даст вам то, что вы ищете, отобразит все ваше приложение, показывая разные поколения. Это бесплатная загрузка от Microsoft, и она чрезвычайно мощная и простая в использовании. Я также включил ссылку на то, как его использовать. (CLR Profiler Download) (Как использовать CLR Profiler)

Answer 3

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

Пробная версия NDepend находится в свободном доступе, поэтому стоит попробовать проанализировать сборки, как вашу, так и стороннюю.

Answer 4

Операции упаковки и распаковки могут быть обнаружены путем статического анализа вашего кода. Ищите правила fxcop.

Профилировщик может также помочь вам, так как такое большое количество выделений в секунду, несомненно, вызовет большие издержки.

Удачи и держите нас в курсе ваших результатов.

Answer 5

Очень технологичный, но удивительно эффективный подход - подключить отладчик и каждый раз нажимать паузу и видеть, где останавливается программа.

Если вы выделяете достаточное количество времени для запуска большой активности GC, тогда у вас есть хорошие шансы взломать код, в котором происходит распределение по боксу.

Преимущество этого в том, что вам не нужны новые инструменты (при условии, что у вас есть достойная IDE или отладчик)

Answer 6

Я думаю, GlowCode может сообщить, где происходит бокс типов значений, хотя вам нужно прокрутить опции, чтобы узнать, как его включить.