Как-то было свободных полчаса перед встречей. Ни туда, ни сюда. Дай, думаю, сниму трейс с приложения. Вдруг что-то интересное найдётся.

А в качестве бонуса: использование var может привести к багам? Узнаем в самом конце ;)

Сложная и тяжелая статья с непропорционально простым выводом. Вспомним фон Неймана, затронем процессорный кеш, поговорим про регистры и компиляторы. Тем, кому не хочется погружаться в детали, достаточно прочитать только Введение и Выводы.

Нечасто встречаются истории, когда причины и следствия сплетаются в один клубок, связывающий проблемы и с памятью, и с CPU, и с тредпулом. А инструментально затрагивающие и пулы объектов, и Lazy, и работу с асинхронностью, и длительные вычисления. А ещё реже встречаются те, где всё это распутывается и исправляется буквально несколькими строчками кода.

Короткая зарисовка о том, почему важно осознанно писать каждую строчку кода, каждый символ. А заодно и небольшой мастер-класс по использованию dottrace и класса string одновременно.

Все слышали о том, что иногда dotnet на Linux потребляет больше ресурсов, чем на Windows. Порой эта разница практически незаметна. Но случается и такое, что одно и то же приложение потребляет на Linux в 2–3 раза больше CPU, чем на Windows.

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

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

Ходят слухи, что foreach быстрее for. А ещё ходят слухи, что for быстрее foreach. Пора разобраться, что быстрее!

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

Сегодня мы продолжим щупать тредпул. Будем подсовывать ему наши специальные задачи и с помощью них изучать, как он себя ведёт. Как выглядит его работа снаружи. И, надеюсь, это позволит сделать ещё один шаг в сторону понимания его устройства.

Конвейер трудится изо всех сил, чтобы повысить производительность твоей программы. А злобные «if»'ы нагло врываются посреди его работы и всё портят!

На сколько полезен конвейер в современных ЭВМ? Как сильно мешаются ветвления в коде, которые ты написал? И как архитекторы процессоров сглаживают ущерб, который «if»'ы наносят по производительности программ?

Современные процессоры очень круты. Они таят в себе великое множество секретов и невероятных возможностей. И просто восхитительно, что некоторые из способностей процессоров легко продемонстрировать даже из такого высокоуровневого языка, как C#, буквально за десять строчек кода!

А вы никогда не задумывались, что async и await выглядят как-то инородно среди прочего C# кода? Больше нигде не встречается такого странного синтаксиса и таких модификаторов, кроме как в методах, работающих с Task и Task<T>.

А ещё интересно, сколько вообще стоит пользоваться async/await? И когда можно (нужно?) обходиться без них?

А вы никогда не задумывались, что yield return выглядит как-то инородно среди прочего C# кода? Больше нигде не встречается такого странного синтаксиса и такой инструкции, кроме как внутри методов, возвращающих перечисление.

А ещё интересно, сколько же на самом деле стоит перечислять элементы с помощью yield return? И можно ли лучше?

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

Тема тредпула, скажем так, complex and hard. У меня в жизни было два «осознания», когда я гордо говорил себе — вот теперь-то я точно понял, как устроен и как работает тредпул в дотнете! Впрочем, после второго раза я неоднократно осознавал, как же я ошибался.

Иногда приходится разбираться, почему .NET приложение работает "плохо". Не так, как мы ожидали. Тупит, медленно работает, зависает, запросы «не исполняются», утекает память или потребляется слишком много CPU.

Есть множество способов, как разбираться в таких ситуациях. Сегодня мы немного обсудим, что это за способы. Когда и какой способ нужно использовать. И более детально рассмотрим один из инструментов: PerfView.

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

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

C#. Guid.NewGuid(). Linux. Windows. Randomness or Uniqueness. RNG and PRNG. Performance. Benchmarking.

Цель нашей сегодняшней сказки — развлечься как следует. Детективная история в поисках потерянного перфоманса с красивым финалом и эффектным результатом непосредственно связана с набором слов из предыдущего абзаца.