Измеряем время выполнения кода через Stopwatch — без догадок

Иногда кажется, что «этот метод тормозит», но без цифр это только ощущение. В .NET есть готовый инструмент для честного замера времени — класс Stopwatch.

Сначала подключим нужное пространство имён — оно лежит в System.Diagnostics:

using System;
using System.Diagnostics;

Теперь померяем, сколько времени занимает простой цикл с подсчётом суммы.
Создаём Stopwatch, запускаем, выполняем код, останавливаем и выводим результат:

var stopwatch = Stopwatch.StartNew(); // запускаем таймер

long sum = 0;
for (int i = 0; i < 10_000_000; i++)
{
    sum += i;
}

stopwatch.Stop(); // останавливаем таймер

Console.WriteLine($"Сумма: {sum}");
Console.WriteLine($"Время выполнения: {stopwatch.ElapsedMilliseconds} мс");

Возможный вывод в консоли может выглядеть так:

Сумма: 49999995000000
Время выполнения: 35 мс

Stopwatch удобно использовать как «обёртку» вокруг любого участка кода: до него — StartNew(), после — Stop() и чтение ElapsedMilliseconds или Elapsed.

🔥Главное — не гадать «быстро или медленно», а мерить цифрами через Stopwatch и уже по ним решать: оптимизировать участок, менять алгоритм или оставить как есть.

➡️ C# Ready | #практика

Как не городить try/catch вокруг каждого вызова?

В бизнес-логике часто у каждой операции свой try/catch: обрабатываем заказ, отправляем письмо, пишем в лог — и везде одинаковый catch с логированием и сообщением пользователю:

try { ProcessOrder(orderId); }
catch (Exception ex) { Log(ex); ShowError("Что-то пошло не так"); }

try { SendEmail(orderId); }
catch (Exception ex) { Log(ex); ShowError("Что-то пошло не так"); }

С фильтрами в catch обработку ошибок можно вынести в одно место. В try остаётся чистый, линейный код, а любой выброшенный Exception попадает в один catch.

🔥 Условие when (LogError(ex)) сначала логирует ошибку, затем возвращает true, поэтому блок обработки выполнится только после успешного логирования.

➡️ C# Ready | #совет

☕️ Catlike Coding — отличный сайт по графике и Unity!

Здесь понятно объясняют вещи, которые обычно подают слишком сложно: шейдеры, освещение, шумы, работа рендера. Все уроки идут с визуализациями и примерами, поэтому даже сложная тема воспринимается легко.

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

📌 Оставляю ссылочку: catlikecoding.com

➡️ C# Ready | #ресурс

Мини-кеш в памяти через MemoryCache — меньше лишних запросов к БД!

Когда данные меняются редко, но читаются постоянно (настройки, справочники, профили), тянуть их каждый раз из БД или файла — расточительно. Проще один раз загрузить и держать в памяти пару минут, используя MemoryCache.

Сначала подключим нужные пространства имён и создадим кеш:

using System;
using Microsoft.Extensions.Caching.Memory;

var cache = new MemoryCache(new MemoryCacheOptions());

Теперь сделаем метод, который сначала пытается взять данные из кеша, а если их там нет — читает из «БД» и кладёт в кеш на 5 минут:

string GetUserName(int userId)
{
string cacheKey = $"user:{userId}";

if (!cache.TryGetValue(cacheKey, out string name))
{
    Console.WriteLine("Читаем из БД...");
    name = LoadUserNameFromDatabase(userId);

    // кэшируем на 5 минут
    cache.Set(cacheKey, name, TimeSpan.FromMinutes(5));
}

return name;
}

Для примера сделаем простую «заглушку» под запрос к БД:

string LoadUserNameFromDatabase(int userId)
{
// здесь могла бы быть реальная работа serId}";
}

Теперь посмотрим, как это работает при двух подряд вызовах с одним и тем же userId:

Console.WriteLine(GetUserName(42)); // первый вызов — попадём в "БД"
Console.WriteLine(GetUserName(42)); // второй вызов — уже из кеша

Возможный вывод в консоли:

Читаем из БД...
User #42
User #42

🔥 Обрати внимание: сообщение «Читаем из БД…» появилось только один раз — дальше значение берётся из памяти, пока не истечёт время жизни записи (в нашем примере 5 минут).

➡️ C# Ready | #практика

Как избавиться от конкатенации строк в логах?

В старом коде логи часто собирают через +: дописываем кусочки текста, ID пользователя, источник, детали ошибки — и в итоге получаем длинную, плохо читаемую строку.

_logger.LogWarning(
    "User " + userId + " not found in " + source);

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

С интерполяцией и шаблонами сообщения становятся короче и понятнее:

_logger.LogWarning("User {UserId} not found in {Source}", userId, source);

Текст читается как обычное предложение, а значения подставляются отдельными аргументами. Логгер может сохранить их структурированно — по полям UserId, Source, что упрощает фильтрацию и поиск.

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

➡️ C# Ready | #совет