Производительность средства выделения объектов .NET

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

С выпуском Visual Studio 16.10 появился новый механизм анализа для профилировщика производительности, при этом .NET Object Allocation Tool (средство выделения объектов .NET) стало первым встроенным инструментом. Это дает инструменту некоторые новые функции и значительное повышение производительности. Попробуйте это в своем приложении C# и посмотрите, какие ложные выделения вы можете удалить, чтобы ускорить работу вашего приложения.

Что нового

В .NET Object Allocation Tool теперь есть поддержка Source Link, которая позволяет инструменту извлекать исходные файлы при переходе к исходнику. Это позволяет вам точно видеть, где происходит выделение, даже если их нет в вашем коде.

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

Наконец, мы добавили дополнительную информацию в представление «Коллекции», чтобы попытаться лучше настроить работу .NET Garbage Collector (GC). Теперь вы можете увидеть, почему сработал сборщик мусора, а также соответствующую статистику, например, сколько времени это заняло, размер и сколько объектов было собрано.

Немного цифр

Одна из областей, на которую мы потратили больше всего энергии, - это повышение производительности .NET Object Allocation Tool. Для этого мы сосредоточились на двух больших задачах, которые выполняет инструмент:

  • Построение начальной модели распределения, которая используется для поиска распределения для представлений.

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

В таблице ниже вы можете увидеть, что гораздо быстрее этот инструмент находится в последней версии Visual Studio.

ASP.NET Scenarios App

Build Allocation Model

Build Call Tree

Small trace (500K allocations)

3.5s -> 2.2s

~1.5x быстрее

295s -> 24s

~12x быстрее

Medium trace (1M allocations)

6.9s -> 3.6s

~2x быстрее

695 -> 58s

~11x быстрее

Large trace (3.1M allocations)

22.5s -> 8.4s

~2.5x быстрее

1556s -> 109s

~14x быстрее

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

Это только начало, первый инструмент. Мы распространяем эти изменения на другие инструменты в профилировщике производительности для Visual Studio 2022 и у нас есть дополнительные идеи о том, как мы можем сэкономить еще больше времени. Ожидайте, что ваш опыт профилирования станет намного быстрее!

Источник: https://habr.com/ru/company/microsoft/blog/566546/


Интересные статьи

Интересные статьи

Практически в каждом секторе, работающем со сложными данными, Spark "де-факто" быстро стал средой распределенных вычислений для команд на всех этапах жизненного цикла дан...
Мониторинг событий информационной безопасности автоматизируют с использованием различных средств защиты: LM/SIEM, UBA/UEBA, IRP/SOAR, TIP, IDS/IPS, NTA, EDR. Объединение ...
Ни для кого не секрет, что в дотнет завезли интринсики. Я писал об этом и до того, как они появились и после. Плюс ещё посты на Хабре, например этот. И всё, казалось бы, замечательно,...
Библиотеки .NET Core — один из самых популярных C# проектов на GitHub. Неудивительно, с учётом его широкой известности и используемости. Тем интереснее попробовать выяснить, какие тёмные уголки...
В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes. Битрикс, Kubernetes, Сep...