Ставьте лайки и подписывайтесь! А то как то совсем грустно.
Это очередная статья по выбору WebRequest или HttpClient. Переходим к цифрам, чтобы понять есть ли смысл кучу legacy кода переводить на HttpClient - мы замерим производительность старого и нового метода и посмотри стоит ли оно того.
BenchmarkDotNet
Будем использовать этот фреймворк. Создаем проект - консольное приложение. Добавляем nuget пакет BenchmarkDotNet.
Далее создаем класс с бенчмарками
Создаем метод для каждого из наших методов и отмечаем эти методы флагом [Benchmark].
Остановлюсь только на трех строках
9 - говорим о том что нам нужно собрать инфу по памяти тоже
10 - сортируем от быстрого к медленному
11 - ранжируем результат
Далее в файле Program.cs добавляем одну строку
BenchmarkRunner.Run<GptApiClientBenchmarks>();
В общем то и все. Теперь у нас есть библиотека и модуль для проверки производительности.
Теперь как запустить наши бенчмарки. Важно понимать, что расчет производительности должен производится с конфигом release. Поэтому делаем релизную сборку. Из корня с исходниками запускам
dotnet build -c Release
Находим куда собралось наше консольное приложение и вызываем команду
sudo dotnet путь/DailyPosta.Benchmark.Gpt.dll
Ждем какое то время и смотрим что получилось.
Ну и в общем я этого не ожидал. По времени выполнения все одинаково. Но вот памяти на HttpClient выделяется в 4 раза больше (Allocated). Да уж...
Еще важный момент в бенчмарках нельзя использовать async/await поэтому в конце бенчмаркируемого метода ставим .Wait()
Спасибо за внимание! Чуть позже я добавлю статью, как можно нашу библиотеку развернуть в nuget и выложить так, что доступ был только у вас.
Ставьте лайки и подписывайтесь!
P.S. Я вынес создание HttpClient из метода в конструктор и результат стал таким
В общем HttpClient чуточку лучше.
Важно! Это не совсем показательно, потому что в большей степени мы делаем бенчмарк не нашего метода а вызываемого метода api. Но в развлекательных целях почему бы и нет.
Еще раз спасибо!