Альтернативы SharpLab
В продолжение вчерашнего поста публикую список инструментов, которые могут служить заменой SharpLab.
👩💻 C# Interactive в Visual Studio — встроенный REPL, который запускается через меню View → Other Windows → C# Interactive. Позволяет писать и выполнять C# код в отдельном окне.
👩💻 C# Interactive в Rider — аналогичный инструмент от JetBrains.
👩💻 csharprepl — опенсорсная REPL-утилита. Устанавливается через .NET CLI:
👩💻 dotnet-repl — ещё одна опенсорсная REPL-утилита. Также устанавливается через .NET CLI:
👩💻 Polyglot Notebook — расширение для VS Code. Использовать очень просто: установить, создать .dib файл, выбрать С# и можно писать код. Функционал аналогичен Jupiter Notebook.
⚙️ LINQPad — старая добрая десктопная программа, которая, пожалуй, больше всего по внешнему виду и функционалу похожа на SharpLab. Работает только на Windows и Mac (бета). К сожалению, полноценный функционал доступен только в платной версии, поэтому не очень подходит для рабочей тачки.
🌐 Compiler Explorer — онлайн дизассемблер. Позволяет просматривать только ASM. Поддерживает множество языков и C#, в том числе.
👩💻 dotPeek — бесплатный декомпайлер от JetBrains. Удобен тем, что позволяет смотреть C#, IL и ASM в одном окне. Работает только на Windows.
За рекомендации спасибо @ishvedov и @NSent.
В продолжение вчерашнего поста публикую список инструментов, которые могут служить заменой SharpLab.
dotnet tool install -g csharprepl. Есть автокомплит, Intellisense, подсветка синтаксиса, просмотр IL-кода и даже поддержка OpenAI через Bring Your Own Token. Примеры использования можно посмотреть в репозитории.dotnet tool install -g dotnet-repl. По сравнению с csharprepl, хуже работает подсветка синтаксиса. Совсем нет автокомплита, Intellisense и других фичей.⚙️ LINQPad — старая добрая десктопная программа, которая, пожалуй, больше всего по внешнему виду и функционалу похожа на SharpLab. Работает только на Windows и Mac (бета). К сожалению, полноценный функционал доступен только в платной версии, поэтому не очень подходит для рабочей тачки.
🌐 Compiler Explorer — онлайн дизассемблер. Позволяет просматривать только ASM. Поддерживает множество языков и C#, в том числе.
За рекомендации спасибо @ishvedov и @NSent.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
В продолжение своего вопроса собрал список провайдеров, которые предоставляют бесплатный хостинг PostgreSQL.
В таблице сравнение по лимитам, доступным регионам, бэкапам и другим параметрам. Все сервисы соответствуют критериям:
- Бесплатная регистрация без банковской карты.
- Нет лимита по времени, то есть используемая база данных не будет удалена через определённый промежуток времени.
Везде зарегистрировался и проверил сам.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19
Месяц назад выкладывал статистику с hh.ru. С тех пор продолжаю следить — ежедневно фиксирую количество вакансий в разных разрезах. Вот что есть интересного:
🔹 Самый «вакансийный» день — среда. Затем вторник и четверг. Меньше всего предложений по понедельникам и в выходные. Почему так я не знаю. Может, дело в алгоритмах hh или привычки HR-ов.
🔹 Количество вакансий колеблется в пределах от 2337 до 2544. Разброс небольшой, но есть.
🔹 За месяц — минус 3%. Это разница между медианным количеством вакансий в первую и последнюю неделю наблюдений. Выводы никакие не делаю, т.к. причин может быть множество. Нужно наблюдать.
🔹 С зарплатами без изменений. 48% вакансий с зарплатой предлагают до ₽150к. До ₽400к попадают 95% вакансий.
🔹 С удалёнкой тоже все стабильно: 36%.
Если интересно — продолжу делиться наблюдениями.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Если коротко — мне не понравилось. Слишком много шума и мало пользы. Даже простые баги редко удаётся исправить. Агенты бесконечно генерируют тонны кода, который не работает.
Лучше всего показала себя связка Ask + Edits с ручной проверкой. Например, так я использую её для поиска и исправления багов:
1. Указываю один или несколько проектов, где, предположительно, есть баг.
2. Включаю режим Ask и прошу проанализировать код, найти и объяснить возможное место ошибки.
3. ИИ предлагает участок кода и объясняет, в чём может быть проблема.
4. Проверяю, действительно ли там может быть баг.
5. Если да, то переключаюсь на режим Edits и пишу: «теперь исправь баг». Благодаря общему контексту, Edits использует объяснение из Ask.
6. Жду результата и проверяю. Если не сработало — возвращаюсь к шагу 1.
Делитесь своим опытом использования ИИ. 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Влияние логирования в C# на производительность
English version.
Давно ничего не было про производительность. Сегодня про логирование и как оно влияет на производительность.
Если вы писали такой код:
...то, скорее всего замечали, что IDE настойчиво рекомендовала так больше не делать.
Почему? Потому что интерполированные строки — это синтаксический сахар.
После компиляции код будет выглядеть так:
Проблема здесь в том, что строка text создаётся всегда, даже если уровень логирования выше Debug и сообщение в лог не попадёт.
Более правильный вариант логирования выглядит так:
В этом случае строковый шаблон "Request Id: {Id} finished with Error: {Error}" не будет использоваться, если, например, минимальный уровень логирования Information.
Лишних аллокаций удастся избежать… так я думал, пока не написал бенчмарки и не проверил результаты.
Читать полностью на сайте 👇🏻
P.S. Зацените обновлённый блог. Наконец-то закончил миграцию с Jekyll на Astro.
English version.
Давно ничего не было про производительность. Сегодня про логирование и как оно влияет на производительность.
Если вы писали такой код:
// CA2254: The logging message template
// should not vary between calls
logger.LogDebug($"Request Id: {id} finished with Error: {error}");
...то, скорее всего замечали, что IDE настойчиво рекомендовала так больше не делать.
Почему? Потому что интерполированные строки — это синтаксический сахар.
После компиляции код будет выглядеть так:
var handler = new DefaultInterpolatedStringHandler(34, 2);
handler.AppendLiteral("Request Id: ");
handler.AppendFormatted(value);
handler.AppendLiteral(" finished with Error: ");
handler.AppendFormatted(value2);
string text = handler.ToStringAndClear();
logger.LogDebug(text);
Проблема здесь в том, что строка text создаётся всегда, даже если уровень логирования выше Debug и сообщение в лог не попадёт.
Более правильный вариант логирования выглядит так:
logger.LogDebug("Request Id: {Id} finished with Error: {Error}", Id, Error);В этом случае строковый шаблон "Request Id: {Id} finished with Error: {Error}" не будет использоваться, если, например, минимальный уровень логирования Information.
Лишних аллокаций удастся избежать… так я думал, пока не написал бенчмарки и не проверил результаты.
Читать полностью на сайте 👇🏻
www.alexeyfv.xyz
Влияние логирования в C# на производительность
Как логирование в C# влияет на производительность приложения. Сравнение интерполяции строк, шаблонов и LoggerMessageAttribute.
👍16
xxHash: самый быстрый алгоритм хеширования в экосистеме .NET
Читать на сайте.
Read on website.
Недавно на работе возникла задача: нужно было посчитать стабильный хэш объектов. Я сразу подумал про стандартные криптографические алгоритмы вроде SHA1, SHA256, SHA512 и MD5. Но у них есть два недостатка:
1. Хэш получается большим — от 160 до 512 бит.
2. Возвращается массив байтов, что означает лишние аллокации памяти.
Это подтолкнуло меня к поиску альтернатив. Так я быстро наткнулся на репозиторий xxHash и его реализацию на C#. Отличие xxHash в высокой скорости и возможности получить хэш в виде целого числа.
Важно понимать, что xxHash не криптографический алгоритм — он предназначен для других задач: быстрого хэширования, сравнения данных, создания ключей для кэшей или индексов.
Реализации в .NET
Для использования xxHash в своём приложении нужно установить пакет System.IO.Hashing. В нём есть 4 реализации алгоритма xxHash:
- XxHash32 (32 бита);
- XxHash64 (64 бита);
- XxHash3 (64 бита);
- XxHash128 (128 бит).
Производительность
Я сравнил эти алгоритмы по скорости расчёта хэша между собой. К сравнению также добавил алгоритмы SHA1, SHA2, SHA3 и MD5. Результаты оказались ожидаемыми (на обложке) — xxHash значительно быстрее остальных.
Пример использования
xxHash особенно удобен благодаря следующим фишкам:
– Метод
– Хэш в виде числа. В зависимости от алгоритма можно получить хэш как
– Поддержка работы со
Пример реализации расчёта хэша с xxHash на второй картинке.
Выводы
Использование xxHash для расчёта стабильного хэша позволяет:
– Быстро рассчитать хэш. Это один из самых быстрых алгоритмов.
– Избежать аллокаций. Используя
– Хранить хэш как
Читать на сайте.
Read on website.
Недавно на работе возникла задача: нужно было посчитать стабильный хэш объектов. Я сразу подумал про стандартные криптографические алгоритмы вроде SHA1, SHA256, SHA512 и MD5. Но у них есть два недостатка:
1. Хэш получается большим — от 160 до 512 бит.
2. Возвращается массив байтов, что означает лишние аллокации памяти.
Это подтолкнуло меня к поиску альтернатив. Так я быстро наткнулся на репозиторий xxHash и его реализацию на C#. Отличие xxHash в высокой скорости и возможности получить хэш в виде целого числа.
Важно понимать, что xxHash не криптографический алгоритм — он предназначен для других задач: быстрого хэширования, сравнения данных, создания ключей для кэшей или индексов.
Реализации в .NET
Для использования xxHash в своём приложении нужно установить пакет System.IO.Hashing. В нём есть 4 реализации алгоритма xxHash:
- XxHash32 (32 бита);
- XxHash64 (64 бита);
- XxHash3 (64 бита);
- XxHash128 (128 бит).
Производительность
Я сравнил эти алгоритмы по скорости расчёта хэша между собой. К сравнению также добавил алгоритмы SHA1, SHA2, SHA3 и MD5. Результаты оказались ожидаемыми (на обложке) — xxHash значительно быстрее остальных.
Пример использования
xxHash особенно удобен благодаря следующим фишкам:
– Метод
Append. Он позволяет поэтапно добавлять данные к расчёту хэша без промежуточных аллокаций. – Хэш в виде числа. В зависимости от алгоритма можно получить хэш как
uint, ulong или UInt128, без массива байтов. – Поддержка работы со
Span<T>. Можно использовать стек вместо кучи и избежать лишних аллокаций.Пример реализации расчёта хэша с xxHash на второй картинке.
Выводы
Использование xxHash для расчёта стабильного хэша позволяет:
– Быстро рассчитать хэш. Это один из самых быстрых алгоритмов.
– Избежать аллокаций. Используя
Span и Append, можно рассчитывать хэш, используя только стек и регистры.– Хранить хэш как
uint или ulong. Это всего 4 и 8 байт соответственно. Такие значения хорошо индексируются БД и позволяют упростить структуру SQL запросов. Вместо сложных запросов с множеством условий, можно искать по одному полю: WHERE Hash = ... Это особенно полезно при работе с таблицами, где сотни миллионов строк.👍9
В продолжение вчерашнего поста про xxHash
Коллеги в комментариях подсказали ещё один интересный алгоритм — GxHash. Я посмотрел репозиторий вчера вечером и быстро прогнал бенчмарк (результаты на обложке).
Что понравилось:
– Действительно быстрый. Даже быстрее xxHash.
– Как и xxHash, возвращает хэш в виде uint, ulong или UInt128.
Недостатки:
– Нет NuGet-пакета. Пришлось копировать исходники вручную.
Спасибо за наводку @NSent
UPD: @viruseg нашёл NuGet-пакет. Большое спасибо.
Коллеги в комментариях подсказали ещё один интересный алгоритм — GxHash. Я посмотрел репозиторий вчера вечером и быстро прогнал бенчмарк (результаты на обложке).
Что понравилось:
– Действительно быстрый. Даже быстрее xxHash.
– Как и xxHash, возвращает хэш в виде uint, ulong или UInt128.
– Нет NuGet-пакета. Пришлось копировать исходники вручную.
Спасибо за наводку @NSent
UPD: @viruseg нашёл NuGet-пакет. Большое спасибо.
👍3
Используйте индексаторы вместо методов LINQ
Это часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1826: Use property instead of Linq Enumerable method.
Описание правила
Правило рекомендует не использовать методы First(), Last(), Count() из LINQ с IReadOnlyList<T>:
Вместо этого стоит использовать индексатор или свойство Count:
Анализ производительности
Я написал простой бенчмарк, чтобы проверить, насколько LINQ действительно влияет на производительность. Результаты в репозитории и на диаграмме.
Как видно, разница есть. Но она совсем небольшая — всего несколько микросекунд на моём ноутбуке.
Стоит ли заморачиваться?
В большинстве случаев нет. Прирост производительности минимальный. Но если вы пишете высокопроизводительный код или используете LINQ методы в цикле — возможно код стоит отрефакторить.
Это часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1826: Use property instead of Linq Enumerable method.
Описание правила
Правило рекомендует не использовать методы First(), Last(), Count() из LINQ с IReadOnlyList<T>:
IReadOnlyList<string> list = ["str1", "str2", "str3"];
var first = list.First(); // CA1826
var last = list.Last(); // CA1826
var count = list.Count(); // CA1826
Вместо этого стоит использовать индексатор или свойство Count:
IReadOnlyList<string> list = ["str1", "str2", "str3"];
var first = list[0];
var last = list[^1];
var count = list.Count;
Анализ производительности
Я написал простой бенчмарк, чтобы проверить, насколько LINQ действительно влияет на производительность. Результаты в репозитории и на диаграмме.
Как видно, разница есть. Но она совсем небольшая — всего несколько микросекунд на моём ноутбуке.
Стоит ли заморачиваться?
В большинстве случаев нет. Прирост производительности минимальный. Но если вы пишете высокопроизводительный код или используете LINQ методы в цикле — возможно код стоит отрефакторить.
👍6
Скриптинг на C# всё ближе
Microsoft продолжает двигаться в сторону упрощения C#. В свежем видео они показали функционал, позволяющий запускать cs-файлы без sln и csproj. Фича доступна в Preview версии .NET 10.
Пример:
Работает даже с NuGet-пакетами прямо в файле:
Как выглядит результат - на скриншоте.
Пока не совсем ясно, будет ли возможность запускать такие файлы в Docker, то есть через Runtime, а не через SDK.
Microsoft продолжает двигаться в сторону упрощения C#. В свежем видео они показали функционал, позволяющий запускать cs-файлы без sln и csproj. Фича доступна в Preview версии .NET 10.
Пример:
dotnet run hello.cs
Работает даже с NuGet-пакетами прямо в файле:
#:package Spectre.Console@0.50
#:package Spectre.Console.Cli@0.50
using Spectre.Console;
AnsiConsole.Markup("[underline red]Hello[/] [underline green]World![/]");
Как выглядит результат - на скриншоте.
Пока не совсем ясно, будет ли возможность запускать такие файлы в Docker, то есть через Runtime, а не через SDK.
👍8👎2
StringBuilder: избегайте ToString при использовании Append
Read on website.
Читать на сайте.
Это новая часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1830: Prefer strongly-typed Append and Insert method overloads on StringBuilder.
Описание правила
Правило рекомендует не преобразовывать значения в строку при вызове методов Append или Insert.
Вместо этого лучше передать значение напрямую:
Это правило касается примитивных типов вроде byte, short, int, double, long и других.
Анализ производительности
Я написал простой бенчмарк, чтобы оценить, насколько эти подходы отличаются по производительности. Результаты в репозитории и на диаграмме.
Разница по времени — небольшая: около 5 микросекунд на моём ноутбуке. Разница по памяти более заметная: около 20 кБ.
Как работает эта оптимизация?
Когда вы используете метод Append(int), под капотом StringBuilder вызываются методы AppendSpanFormattable<T> и InsertSpanFormattable<T>.
Например, упрощённая версия AppendSpanFormattable<T> выглядит так:
Этот метод использует интерфейс ISpanFormattable.TryFormat, чтобы записать значение напрямую во внутренний буфер StringBuilder как Span<char>. Это позволяет: избежать аллокации строки; упаковки (boxing) и вызова виртуального метода ToString().
Стоит ли заморачиваться?
Скорее да. Даже если не брать в расчёт прирост производительности, такой код:
и выглядит проще и чище, чем:
И в качестве бонуса, он работает быстрее и потребляет меньше памяти. Win-win.
Read on website.
Читать на сайте.
Это новая часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1830: Prefer strongly-typed Append and Insert method overloads on StringBuilder.
Описание правила
Правило рекомендует не преобразовывать значения в строку при вызове методов Append или Insert.
var i = 123;
var sb = new StringBuilder();
sb.Append(i.ToString()); // CA1830
Вместо этого лучше передать значение напрямую:
var i = 123;
var sb = new StringBuilder();
sb.Append(i);
Это правило касается примитивных типов вроде byte, short, int, double, long и других.
Анализ производительности
Я написал простой бенчмарк, чтобы оценить, насколько эти подходы отличаются по производительности. Результаты в репозитории и на диаграмме.
Разница по времени — небольшая: около 5 микросекунд на моём ноутбуке. Разница по памяти более заметная: около 20 кБ.
Как работает эта оптимизация?
Когда вы используете метод Append(int), под капотом StringBuilder вызываются методы AppendSpanFormattable<T> и InsertSpanFormattable<T>.
Например, упрощённая версия AppendSpanFormattable<T> выглядит так:
private StringBuilder AppendSpanFormattable<T>(T value) where T : ISpanFormattable
{
if (value.TryFormat(
RemainingCurrentChunk,
out int charsWritten,
format: default,
provider: null))
{
m_ChunkLength += charsWritten;
return this;
}
return Append(value.ToString());
}
Этот метод использует интерфейс ISpanFormattable.TryFormat, чтобы записать значение напрямую во внутренний буфер StringBuilder как Span<char>. Это позволяет: избежать аллокации строки; упаковки (boxing) и вызова виртуального метода ToString().
Стоит ли заморачиваться?
Скорее да. Даже если не брать в расчёт прирост производительности, такой код:
sb.Append(i);
и выглядит проще и чище, чем:
sb.Append(i.ToString());
И в качестве бонуса, он работает быстрее и потребляет меньше памяти. Win-win.
👍8
Два месяца назад публиковал список бесплатных сервисов PostgreSQL. Напомню, что это список провайдеров, которые предоставляют бесплатный хостинг PostgreSQL и соответствуют следующим критериям:
- Бесплатная регистрация без банковской карты.
- Нет лимита по времени, то есть используемая база данных не будет удалена через определённый промежуток времени.
За это время проект получил 23 звезды и 1 пул реквест. Два сервиса были удалены из списка, и два новых добавлены.
✅ Новые сервисы
Xata.io Lite – предоставляет бесплатный тариф с 15 ГБ и ежедневными бэкапами.
Rapidapp.io – бесплатный план с 20 МБ хранилища.
❌ Удалённые сервисы
Tembo.io – отменили бесплатный план с 30 мая. Жалко, т.к., на мой взгляд, у этого провайдера были самые адекватные условия.
Turso.tech – удалён, так как это SQLite as a Service, а не PostgreSQL (добавил по ошибке).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Последние несколько недель максимально погружен в работу, поэтому публикаций не так много. Но появился интересный кейс, о котором хочется рассказать.
Задача
Нужно было скачать большие csv-файлы, прочитать их, отфильтровать нужные строки и загрузить в базу данных. Под большими я имею в виду файлы по 0,5–1 ГБ – это месячные отчёты от облачных провайдеров о расходах.
Это стандартная ETL-задача. Сложность была в том, что у подов в нашем Kubernetes-кластере ограничение по памяти на 250 МБ. Можно было просто поднять лимит, но это слишком просто и неинтересно. Я решил попробовать сделать всё с минимальными затратами памяти.
Пост не влезает в Telegram, поэтому продолжение на сайте.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Последние два месяца я пишу мало, т.к. работа отнимает много сил. Но не могу не рассказать, как в прошлом месяце я мигрировал проект с SQL Server на PostgreSQL.
Предыстория
Проект, над которым работаю в данный момент, – это FinOps приложение для аналитики трат на облачные провайдеры. В первоначальной версии дашборда, которую мы сделали 2 года назад, в качестве хранилища использовалась SQL Server. Это основная база данных для приложений у нас в команде. Данные обрабатывались при помощи OLAP-кубов из SQL Server Analytics Services (SSAS).
В начале лета к нам пришёл запрос на доработку дашборда. Доработка затрагивала многие аспекты приложения, из-за чего приложение пришлось практически переписать. Поэтому заодно я решил и мигрировать проект на Postgres.
Почему отказались от SSAS
1. Для OLAP-кубов SSAS есть отдельный тип проектов, который поддерживается только Visual Studio. Ничего не имею против Visual Studio, но когда ты Full Stack инженер, которому приходится работать с C#, TypeScript, React, Docker, Kubernetes, Helm, то Visual Studio не самый подходящий выбор.
2. Несмотря на то, что Visual Studio – это единственная IDE, поддерживающие такие проекты, она периодически крэшится и зависает при работе с ними.
3. Деплой OLAP-куба возможен только через Visual Studio. Настроить деплой через CI/CD нельзя.
4. Синтаксис запросов Analytics Services (MDX) отличается от SQL:
-- SQL
SELECT service, SUM(cost) AS cost
FROM costs
WHERE provider='AWS' AND environment_tag='prod'
AND date >= DATE '2025-08-01' AND date < DATE '2025-09-01'
GROUP BY service
ORDER BY cost DESC
FETCH FIRST 3 ROWS ONLY;
-- MDX
SELECT
{ [Measures].[Cost] } ON COLUMNS,
TopCount([Service].[Name].Members, 3, [Measures].[Cost]) ON ROWS
FROM [Cloud FinOps]
WHERE ( [Date].[Calendar].[Month].&[2025]&[8],
[Provider].[Provider].&[AWS],
[Tags].[Environment].&[prod] )
5. Запуск перерасчёта OLAP-куба из приложения в Docker требует танцев с бубнами. Есть кроссплатформенные библиотеки от Microsoft, но они не работают из коробки.
Всё это послужило причиной переезда на Postgres с использованием материализованных представлений (Materialized Views). В SQL Server тоже есть похожий функционал (Indexed Views), но их создание и поддержка сложнее.
Lessons Learned
Теперь о том, какой опыт я приобрёл, пока делал миграцию проекта.
1. Потоковая вставка данных в Postgres проще, чем в SQL Server.
В предыдущем посте я рассказывал, как записать большой массив данных в SQL Server. Так вот, в Postgres это делается значительно проще. Не нужно писать портянки кода, реализовывая интерфейс IDataReader.
2. Материализованные представления способны заменить OLAP-куб.
Пара десятков представлений покрывают все потребности нашего дашборда. При этом, используется обычный SQL синтаксис, который знаком любому инженеру.
3. Использование каскада представлений позволяет уменьшить время обновления.
Каскад материализованных представлений (cascade / nested materialized views) – это техника, при которой одно материализованное представление строится на основе другого MV, а то на основе третьего, и так далее. Например, сначала агрегируем данные по дням, потом по месяцам, а затем, агрегируем траты по категориям ресурсов для конкретного месяца.
4. Главная таблица (Fact Table) должна занимать как можно меньше места.
Уменьшение размера строки даже на несколько байт может сэкономить гигабайты памяти, что улучшит скорость выполнения запросов.
К примеру, у нас каждый месяц от трёх облачных провайдеров суммарно приходит около 12 млн событий. Строка Fact Table сейчас состоит из 3-х столбцов: Timestamp (Date, 4 байт), Cost (decimal, примерно 8 байт), ResourceId (integer, 4 байт). Добавление, например, столбца Id в качестве первичного ключа спокойно может увеличить размер таблицы на 100 – 200 Мб в месяц (размер столбца + размер индекса первичного ключа).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8