Дорогой throw #статья #скорость

Изучаю производительность методов, в которых выбрасывается ошибка, вот тут, на Хабре и на Дзен.

Перебираем массив #статья #скорость #память

Освежаю знания о том, как быстрее всего бежать по массиву вот тут, на Хабре и на Дзен.

Дорогие замыкания #статья #память

Снижаю аллокацию при замыкании (closure) и бенчмаркаю производительность вот тут, на Хабре и на Дзен.

Специальный словарь #статья #скорость #память

Пишу специальный Dictionary<int, TValue>, где TValue всегда структура и её можно получить по ссылке вот тут, на Хабре и на Дзен.

System design #архитектура

Оказывается, что есть люди, которые ещё не читали вот этот набор примеров по дизайну систем. С описанием требований, дискуссиями за и против, схемами. Всем рекомендую.

Почему это актуально? Ну, например, относительно недавно на собеседовании в одну немаленькую контору, мне предложили рассказать фактически вот это, про Twitter. Собеседование состояло из трёх секций, эта секция называлась "дизайн информационных систем" (system design). Популярная штука, рекомендую подготовиться заранее.

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

Dragonfly #решение

Если кто пропустил, ребята написали свой Redis и назвали это Dragonfly. Сообщают о приросте производительности в 25 раз и экономии 30% памяти. Я погонял на пет проекте с помощью memtier_benchmark и пары скриптов в Postman - остался доволен.

Сегодня я снова услышал про Dragonfly в подкасте RadioDotNet. Оказывается, автор RavenDB (БД на C#) тоже написал пару строк о "своём Redis'е". Естественно, с использованием C#. Чтение занимательное, рекомендую.

Вообще, мне нравится любое движение в сторону увеличения производительности. Не смотря на то, что, кажется, "дешевле купить ещё памяти" или "докинуть процессоров", я регулярно слышу "сервис потребляет слишком много ресурсов", "на эти деньги можно нанять ещё программистов" или "кэш работает слишком медленно". Я уверен, что программы должны работать быстро, а ресурсы нужно экономить, поэтому что они либо дороги, либо конечны.

17 сентября в Нижнем Новгороде будет конференция по .NET. Расскажут про культуру документации, надёжные интеграции и MediatR. Про микрооптимизации буду вещать я.

#лекция

Давайте рассказывать про ЗП #деньги

Я люблю писать и беседовать про деньги, но это почему-то не всегда приветствуется. Тем не менее, я считаю, что это важно. Это позволяет коллегам знать о том, что они чего-то стоят.

Недавно получил подтверждение, что наши компании способны давать весьма конкурентную зарплату. Я имел удовольствие сравнивать предложение компании из Силиконовой долины и нашего аналога IKEA. Батл вышел великолепный, но, на удивление, равный.

Из США предлагали древнее легаси на C#, полное отсутствие микросервисов и всяких модных шутк, но за очень приличные деньги.

Наши давали архитектора, без возможности программировать, но за бОльше деньги. Микросервисы, нормальные технологии, полный фарш. Из минусов - зарплата формируется из оклад + премия. В принципе, это нормальная практика.

Почему я это пишу? Я сторонник открытых цифр по зарплате, так как это помогает нам (работникам) понимать, а, собственно, сколько мы стоим. И, надеюсь, это позволит всем нам не соглашаться на полумеры.

В преддверии мероприятия, я рекомендую ознакомиться с интересными статьями: почему не нужно использовать MediatR (статья на русском тут) и почему его использовать круто.

Вообще, к MediatR у меня много претензий, в том числе по перформансу. Если вы пойдёте по ссылке, я замечу, что эта библиотека не рекомендуемая для работы в проде.

Ещё немного бенчмарков по MediatR можно найти тут. Детальный рассказ по перформансу тут.

#архитектура #решение #скорость #память