English version is below.
Продолжаю сравнивать методы string и ReadOnlySpan<char>.
По результатам бенчмарка, методы Trim, TrimStart, TrimEnd в ReadOnlySpan<char> в среднем на 40% быстрее, чем в string. Ничего удивительного нет, т.к. использование этих же методов в string приводит к аллокациям памяти.
Метод string.CompareTo во всех случаях быстрее, правда незначительно. При использовании StringComparison.Ordinal эта разница достигает 88%.
Метод Equals в ReadOnlySpan<char> демонстрирует сопоставимую производительность с string при использовании CurrentCulture, InvariantCulture и других типах сравнения. Однако при использовании OrdinalIgnoreCase string быстрее ~25%.
String and Span comparison. Part 2. Trim, TrimStart, TrimEnd, CompareTo, Equals
I continue to compare the string and ReadOnlySpan<char> methods.
According to the benchmark results, Trim, TrimStart, and TrimEnd methods in ReadOnlySpan<char> are, on average, 40% faster than in string. This is not surprising, because using these methods in string causes memory allocations.
CompareTo is faster in string in all cases, although only slightly. But when using StringComparison.Ordinal, the difference reaches 88%.
Equals in ReadOnlySpan<char> shows comparable performance to string when using all comparison types except OrdinalIgnoreCase. In this case string is ~25% faster.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
English version is below.
Продолжаю сравнивать методы string и ReadOnlySpan<char>.
Метод Split работает на 46% – 64% быстрее в ReadOnlySpan<char>. Использование метода MemoryExtensions.Split позволяет работать со структурой Range, массив которых можно создать в стеке:
Span<Range> ranges = stackalloc Range[str.Length];
str.AsSpan().Split(ranges, separator);
Методы ToLower и ToUpper также работают на 43% – 45% быстрее в ReadOnlySpan<char>. И опять же, это преимущество достигается за счёт отсутствия аллокаций в куче:
Span<char> destination = stackalloc char[str.Length];
str.AsSpan().ToLower(destination, CultureInfo.InvariantCulture);
Производительность метода CopyTo практически одинаковая — разница составляет всего 3% в пользу ReadOnlySpan. Однако важно учитывать, что массив, в который будет скопирована строка, должен быть заранее проинициализирован. Это можно сделать как в стеке с помощью stackalloc, так и в куче с помощью оператора new, что может влиять на производительность:
// Вариант 1
Span<char> destination = new char[str.Length];
str.CopyTo(destination);
// Вариант 2
Span<char> destination = stackalloc char[str.Length];
str.CopyTo(destination);
Метод Replace в ReadOnlySpan<char> работает на 75% быстрее, чем в string. Это очевидно связано с отсутствием аллокаций при использовании ReadOnlySpan — результат замены сохраняется в отдельный Span:
Span<char> destination = stackalloc char[str.Length];
str.AsSpan().Replace(destination, oldChar, newChar);
I continue to compare the string and ReadOnlySpan<char> methods.
The Split method works 46% – 64% faster with ReadOnlySpan<char>. Using the MemoryExtensions.Split method allows to work with Range. An array of ranges can be created on the stack:
Span<Range> ranges = stackalloc Range[str.Length];
str.AsSpan().Split(ranges, separator);
The ToLower and ToUpper methods are also 43% – 45% faster with ReadOnlySpan<char>. Again, this comes from avoiding allocations on a heap:
Span<char> destination = stackalloc char[str.Length];
str.AsSpan().ToLower(destination, CultureInfo.InvariantCulture);
Method CopyTo has almost the same performance — ReadOnlySpan is only 3% faster. However, it's important to note that the destination array should be pre-initialized. This can be done either on the stack using stackalloc or on the heap using the new operator, which can affect performance:
// Option 1
Span<char> destination = new char[str.Length];
str.CopyTo(destination);
// Option 2
Span<char> destination = stackalloc char[str.Length];
str.CopyTo(destination);
Method Replace in ReadOnlySpan<char> is 75% faster than in string. Again, this is due to the absence of heap allocations when using ReadOnlySpan:
Span<char> destination = stackalloc char[str.Length];
str.AsSpan().Replace(destination, oldChar, newChar);
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
English is below.
Опытные литкодеры знают, насколько нестабильны результаты бенчмарков решений на LeetCode. Одно и то же решение может показывать результаты с большим разбросом. Видимо, они начали что-то с этим делать и на днях изменили подход к замерам:
«Previously, the runtime calculation included overhead processes, but now we only measure the actual time your code takes to run.»
Вольный перевод: Раньше в замеры попадало время холодного старта приложения, а теперь измеряется только время выполнения кода.
С точки зрения бенчмаркинга, это правильное решение. Время холодного старта может значительно искажать результаты микробенчмарков. Однако, это изменение сломало систему рейтинга существующих решений.
Для тех, кто ориентируется только на Big O нотацию, это не должно создать проблем. Остальным придётся смириться с тем, что их старые результаты станут невалидны. Новые решения могут выполняться всего за несколько миллисекунд, тогда как этот же код ранее выполнялся за 100+ мс. При этом на диаграмме отображаются как новые результаты, так и старые, что приводит к тому, что почти любая новая отправка решения приводит к «Beats 100.00%».
Experienced LeetCoders know how unstable the benchmark results can be on LeetCode. The same solution can show results with a big variation. It seems they started fixing it and recently changed the way they measure performance:
«Previously, the runtime calculation included overhead processes, but now we only measure the actual time your code takes to run.»
From a benchmarking perspective, this is the right decision. Cold start can significantly spoil the results of microbenchmarks. However, this change has broken the rating system for existing solutions.
For those who focus only on Big O notation, this shouldn't create any problems. All others have to accept that their old results became invalid. New solutions may run in just a 1-2 milliseconds, while the same code previously ran in over 100 ms. At the same time, both new and old results are displayed on the diagram, leading to nearly any new submission of a solution being marked as «Beats 100.00%».
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
English is below.
На просторах опенсорс-сообщества разгорается новый скандал. Вчера были удалены упоминания мейнтейнеров ядра Linux, чья почта зарегистрирована в зоне *.ru. А сегодня сам Линус Торвальдс накинул 💩 на вентилятор:
Ok, lots of Russian trolls out and about.
It's entirely clear why the change was done, it's not getting reverted, and using multiple random anonymous accounts to try to "grass root" it by Russian troll factories isn't going to change anything.
And FYI for the actual innocent bystanders who aren't troll farm accounts - the "various compliance requirements" are not just a US thing.
If you haven't heard of Russian sanctions yet, you should try to read the news some day. And by "news", I don't mean Russian
state-sponsored spam.
As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian
aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.
Не знаю, к чему всё это приведёт, но печально видеть, как железные занавесы опускаются с обеих сторон, даже в таком интернациональном сообществе, как опенсорс.
A new scandal is growing in the open-source community. Yesterday, mentions of Linux kernel maintainers with emails in the *.ru domain were removed. And today, Linus Torvalds itself made the situation worse by writing this.
I don’t know where all this will lead, but it’s sad to see the iron curtains closing from both sides, even in a community as international as open-source.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3👎3
Сейчас я работаю над статьёй о том, как писать производительный код для работы с коллекциями. В ней будут как базовые советы для начинающих программистов, так и продвинутые. Поскольку статья ещё не готова, держите мем и фрагмент, посвящённый LINQ.
---
В большинстве случаев методы LINQ работают медленнее и используют больше памяти. Это не значит, что LINQ – это плохо. Нет, это очень крутая фича C# и, естественно, я её тоже использую. Однако в некоторых и, подчеркну, редких ситуациях для лучшей производительности стоит писать в императивном стиле. Рассмотрим несколько простых примеров.
Select vs ConvertAll vs императивный стиль
Предположим, у нас есть массив транзакций:
public record class Transaction(
Guid Id,
int Amount,
string Denoscription);
Допустим, нужно получить поле Denoscription для всех элементов массива _transactions. Неважно, зачем нам это, — просто нужно. 🙂 Это можно сделать с помощью Array.ConvertAll, методов Select и ToArray, или вручную. Сравним эти три способа.
// Benchmark 1
Array.ConvertAll(_transactions,
x => x.Denoscription);
// Benchmark 2
_transactions
.Select(x => x.Denoscription)
.ToArray();
// Benchamrk 3
var array = new string[_transactions.Length];
for (int i = 0; i < _transactions.Length; i++) {
array[i] = _transactions[i].Denoscription;
}
// Results
| Method | Mean | Ratio |
|------------------ |-----------:|---------:|
| ArrayConvertAll | 1,296.4 μs | -3% |
| LinqSelect | 1,343.4 μs | baseline |
| ImperativeConvert | 1,250.4 μs | -7% |
Array.ConvertAll работает на 3% быстрее, чем LINQ, а императивный стиль — на 7% быстрее. Да, разница небольшая, но методы LINQ часто используются последовательно, и в итоге суммарное отличие в производительности может оказаться более заметным.
Any vs Exists vs императивный стиль
Рассмотрим второй пример — проверка существования элемента в массиве.
// Benchmark 1
return Array.Exists(_transactions,
x => x.Amount > 1_000_00);
// Benchmark 2
return _transactions
.Any(x => x.Amount > 1_000_00);
// Benchmark 3
foreach (var t in _transactions) {
if (t.Amount > 1_000_000) return true;
}
return false;
// Results
| Method | Mean | Ratio |
|------------------ |-----------:|---------:|
| ArrayExists | 567.9 μs | -39% |
| LinqAny | 926.1 μs | baseline |
| ImperativeExists | 488.5 μs | -47% |
Array.Exists работает на 39% быстрее, чем LINQ, а императивный стиль — почти вдвое быстрее.
---
Я обязательно проверю и другие методы, а также протестирую с массивами разного размера. Но что-то мне подсказывает, что этот раздел будет называться «Избегайте LINQ».
Кстати, напишите в комментариях, с какими проблемами производительности вам приходилось сталкиваться при работе с коллекциями. Если этого ещё нет в статье, я проанализирую, сделаю бенчмарки и включу разбор в статью.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Публикую следующую часть статьи про производительность коллекций. Сегодня про Enumerator.
---
Предположим, у нас есть массив _transactionsArray и список _transactionsList. Сама транзакция выглядит следующим образом:
public record class Transaction(
Guid Id,
int Amount,
string Denoscription);
Существует множество способов пройтись по двум вышеупомянутым коллекциям:
// Индексатор массива
var sum = 0;
for (var i = 0; i < _transactionsArray.List; i++) {
sum += _transactionsArray[i].Amount;
}
// Индексатор списка
var sum = 0;
for (var i = 0; i < _transactionsList.Count; i++) {
sum += _transactionsList[i].Amount;
}
// Энумератор IEnumerable<T>
var sum = 0;
var collection = (IEnumerable<T>)_transactionsArray;
foreach (var item in collection) {
sum += item.Amount;
}
var sum = 0;
var collection = (IEnumerable<T>)_transactionsList;
foreach (var item in collection) {
sum += item.Amount;
}
// Энумератор List<T>
var sum = 0;
foreach (var item in _transactionsList) {
sum += item.Amount;
}
Один из этих способов аллоцирует больше памяти, чем остальные – это приведение _transactionsList к IEnumerable<T>. Причина кроется в реализации энумератора для списков. У типа List<T> есть собственный энумератор-структура.
Если использовать foreach с типом List<T>, то проблем не возникает. Компилятор C# сгенерирует код, который будет использовать эту структуру напрямую.
// Исходный код
var nums= new List<int>();
var sum = 0;
foreach (n in nums) sum +=n;
// Код после компиляции
var nums = new List<int>();
var num = 0;
List<int>.Enumerator enumerator =
nums.GetEnumerator();
while (enumerator.MoveNext()) {
num += enumerator.Current;
}
Но если привести List<T>, например, к IList<T> или IReadOnlyList<T>, т.е. к любому интерфейсу, реализующему IEnumerable<T>, то произойдёт неявная упаковка List<T>.Enumerator. Это происходит из-за того, что IEnumerable<T>.GetEnumerator() возвращает интерфейс IEnumerator<T>.
// Исходный код
var nums = new List<int>();
var collection = (IEnumerable<int>) nums;
var sum = 0;
foreach (n in collection) sum +=n;
// Код после компиляции
var nums = new List<int>();
var collection = ((IEnumerable<int>)nums);
var num = 0;
IEnumerator<int>.Enumerator enumerator =
// упаковка
collection.GetEnumerator();
while (enumerator.MoveNext()) {
num += enumerator.Current;
}
Аналогичный подход с энумераторами также встречается и других коллекциях: LinkedList<T>, Stack<T>, Queue<T> и т.д. Исключением являются, например, массивы.
Насколько упаковка влияет на производительность можно понять из графиков. Бенчмарк 100 раз прошёлся по каждой из коллекции. На первом графике ось Y отображает проценты от бенчмарка с массивом, а на втором — миллисекунды. Шкала оси X в обоих случаях логарифмическая.
Если говорить об абсолютных значениях, разница не так велика — десятки миллисекунд для коллекций размером 100 000 элементов и более. Наибольшее коварство такое поведение представляет, когда у вас много небольших коллекций. Я в своей практике встречал проблему, когда упаковка энумератора приводила к аллокациям десятков и сотен мегабайт. Это было большое дерево директорий, а доступ к дочерним директориям был только через IReadOnlyList<T>.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Используйте диапазоны (Range) только со Span<int>
В предыдущем посте я писал о скрытой аллокации, возникающей из-за упаковки энумератора. В этом посте расскажу об ещё одной скрытой аллокации.
5 лет назад в C# 8.0 появились индексы и диапазоны, которые позволяют получать часть коллекции с помощью удобного синтаксиса. Например, в следующем примере из массива извлекаются все элементы, кроме 2-х первых и 2-х последних:
Это удобно, особенно по сравнению с аналогичной записью через LINQ:
В случае с LINQ мы явно создаём массив с помощью метода ToArray. Однако это можно и не делать, если нужно просто пройтись по выбранным элементам.
Теперь посмотрим на C#-код без синтаксического сахара. При использовании с массивом оператор диапазона всегда создаёт новый массив. При компиляции он преобразуется в вызов RuntimeHelpers.GetSubArray, который и создаёт новый массив.
Если нет необходимости сохранять подмассив, лучше вызвать AsSpan() перед использованием диапазонов.
С точки зрения производительности, создание нового массива и копирование элементов – это затратная операция, особенно в сравнении со слайсами спанов, которые выполняются практически мгновенно. Рассмотрим следующий код:
Добавление AsSpan() перед использованием оператора диапазона позволяет сократить время выполнения в среднем в 2-3 раза (см. график).
В предыдущем посте я писал о скрытой аллокации, возникающей из-за упаковки энумератора. В этом посте расскажу об ещё одной скрытой аллокации.
5 лет назад в C# 8.0 появились индексы и диапазоны, которые позволяют получать часть коллекции с помощью удобного синтаксиса. Например, в следующем примере из массива извлекаются все элементы, кроме 2-х первых и 2-х последних:
int[] arr = [1, 2, 3, 4, 5, 6];
var subarr = arr[2..^2]; // [3, 4]
Это удобно, особенно по сравнению с аналогичной записью через LINQ:
var subarr = arr.Skip(2)
.Take(arr.Length - 2 - 2)
.ToArray();
В случае с LINQ мы явно создаём массив с помощью метода ToArray. Однако это можно и не делать, если нужно просто пройтись по выбранным элементам.
Теперь посмотрим на C#-код без синтаксического сахара. При использовании с массивом оператор диапазона всегда создаёт новый массив. При компиляции он преобразуется в вызов RuntimeHelpers.GetSubArray, который и создаёт новый массив.
// int[] subarr = arr[2..^2]
int[] subArray = RuntimeHelpers
.GetSubArray(array, new Range(2,
new Index(2, true)));
Если нет необходимости сохранять подмассив, лучше вызвать AsSpan() перед использованием диапазонов.
// Исходный код
int[] arr = [1, 2, 3, 4, 5, 6];
var subarr = arr.AsSpan()[2..^2]; // [3, 4]
// После компиляции
Span<int> span = MemoryExtensions.AsSpan(array);
Span<int> subarr = span.Slice(2,
span.Length - 2 - 2);
С точки зрения производительности, создание нового массива и копирование элементов – это затратная операция, особенно в сравнении со слайсами спанов, которые выполняются практически мгновенно. Рассмотрим следующий код:
start = Length / 4;
end = Length * 3 / 4;
var sum = 0;
// 2-3 times faster:
// _transactionsArray.AsSpan()[_start.._end];
var sliced = _transactionsArray[start..end];
foreach (var t in sliced) sum += t.Amount;
return sum;
Добавление AsSpan() перед использованием оператора диапазона позволяет сократить время выполнения в среднем в 2-3 раза (см. график).
👍7
EventFlow – опенсорс библиотека для DDD, Event Sourcing и CQRS
Немного отвлечёмся от бенчмарков. Уже 2 недели работаю над pet-проектом с DDD + ES + CQRS. Для этого искал подходящую библиотеку, т.к. хотелось сосредоточиться на бизнес-проблемах, а не изобретать велосипед. Нашёл фреймворк EventFlow. В библиотеке есть всё готовое:
- базовые классы для агрегатов и доменных событий;
- команды, запросы;
- обработчики команд, запросов, событий;
- функционал для паттерна «сага»;
- функционал для миграций событий.
и многое другое.
Документация написана достаточно подробно, главное внимательно читать. Я, например, проглядел, что по умолчанию фреймворк «проглатывает» исключения, выброшенные в хэндлерах команд. Из-за этого долго не мог понять, почему некоторые тестовые моки интерфейсов выбрасывают исключения, но это не приводит к поломке тестов.
Альтернативы
В процессе поиска нашёл несколько других проектов по теме. Возможно, кому-то пригодится, поэтому делюсь списком.
1. Revo – ещё одна библиотека для DDD, Event Sourcing и CQRS. Изначально я попытался запустить проект именно с ней, но мне она не понравилась по нескольким причинам:
- Проект крэшился сразу после запуска. Связано это с тем, что Revo построен вокруг Ninject – сторонней библиотеки для внедрения зависимостей, а не встроенного в .NET DI. Исправить я это не смог, из-за плохо написанной документации.
- Функционал библиотеки разбит на множество Nuget-пакетов. Пришлось несколько раз возвращаться к документации, чтобы понять какой очередной пакет установить, чтобы проект наконец-то уже собрался.
У проекта много звёзд, так что, возможно, библиотека не так плоха, а это я не смог разобраться. 🤷♂️
2. Marten DB – Event Store построенный вокруг PostgreSQL. Подходит, если вы хотите самостоятельно разработать базовые классы для агрегатов, событий, команд, запросов, шин сообщений и т. д.
3. YesSQL – интерфейс, имитирующий документоориентированную БД. Библиотека построена поверх EF Core и работает c SQLite, PostgreSQL, SQL Server и MySQL. Думаю, что тоже подходит для создания Event Store.
Немного отвлечёмся от бенчмарков. Уже 2 недели работаю над pet-проектом с DDD + ES + CQRS. Для этого искал подходящую библиотеку, т.к. хотелось сосредоточиться на бизнес-проблемах, а не изобретать велосипед. Нашёл фреймворк EventFlow. В библиотеке есть всё готовое:
- базовые классы для агрегатов и доменных событий;
- команды, запросы;
- обработчики команд, запросов, событий;
- функционал для паттерна «сага»;
- функционал для миграций событий.
и многое другое.
Документация написана достаточно подробно, главное внимательно читать. Я, например, проглядел, что по умолчанию фреймворк «проглатывает» исключения, выброшенные в хэндлерах команд. Из-за этого долго не мог понять, почему некоторые тестовые моки интерфейсов выбрасывают исключения, но это не приводит к поломке тестов.
Альтернативы
В процессе поиска нашёл несколько других проектов по теме. Возможно, кому-то пригодится, поэтому делюсь списком.
1. Revo – ещё одна библиотека для DDD, Event Sourcing и CQRS. Изначально я попытался запустить проект именно с ней, но мне она не понравилась по нескольким причинам:
- Проект крэшился сразу после запуска. Связано это с тем, что Revo построен вокруг Ninject – сторонней библиотеки для внедрения зависимостей, а не встроенного в .NET DI. Исправить я это не смог, из-за плохо написанной документации.
- Функционал библиотеки разбит на множество Nuget-пакетов. Пришлось несколько раз возвращаться к документации, чтобы понять какой очередной пакет установить, чтобы проект наконец-то уже собрался.
У проекта много звёзд, так что, возможно, библиотека не так плоха, а это я не смог разобраться. 🤷♂️
2. Marten DB – Event Store построенный вокруг PostgreSQL. Подходит, если вы хотите самостоятельно разработать базовые классы для агрегатов, событий, команд, запросов, шин сообщений и т. д.
3. YesSQL – интерфейс, имитирующий документоориентированную БД. Библиотека построена поверх EF Core и работает c SQLite, PostgreSQL, SQL Server и MySQL. Думаю, что тоже подходит для создания Event Store.
👍7
Около месяца назад я вписался в C# Advent Calendar — онлайн-мероприятие, организованное Мэтью Гроувсом, энтузиастом C# и автором книги «Аспектно-ориентированное программирование на .NET».
Суть мероприятия в следующем: с 1 по 25 декабря на сайте csadvent.christmas дважды в день публикуются статьи от авторов о разработке на C# и .NET. Моя статья выйдет 9 декабря. Я как раз завершаю над ней работу. В статье я расскажу об одном интересном паттерне для высокой производительности: будут примеры реализации паттерна на C#, разбор внутренностей, бенчмарки и графики. Статья будет на английском, но сюда обязательно опубликую перевод.
Если в адвенте будут интересные статьи, то раз в неделю буду делиться подборкой.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21
Как и обещал, выкладываю самое интересное за первую неделю на C# Advent 2024.
Очень интересный челлендж со строками. Нужно сделать так, что бы программа ниже вывела “Advent of C#”.
Initialize();
var happyHolidays = "Merry Christmas";
// should output: Advent of C#
Console.WriteLine(happyHolidays);
static void Initialize() {
// Your implementation here
}
Сложность в том, что:
- Изменения можно вносить только в метод Initialize.
- Нельзя менять сигнатуру метода.
- Нельзя использовать Console внутри метода Initialize.
- Нельзя использовать стандартный выходной поток.
Автор рассматривает несколько решений. Все они связаны с поведением .NET при работе со строками-литералами, пулом интернирования строк и указателями.
Статья о том, как избежать проблем с множеством зависимостей в классах. Но я бы назвал её «Как не надо проектировать системы». Честно говоря, я не представляю, как можно получить контроллер, в который внедряются 34 зависимости. 😵💫 Это не шутка – смотрите пример из статьи.
Благодаря Minimal API и Primary Constructors автор решает проблему с большим количеством зависимостей, но мне кажется, корень проблемы лежит немного в другой плоскости.
---
В понедельник утром публикуется моя статья. Версию на русском опубликую на Хабре.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
English is below.
Пул объектов (Object Pool) — это паттерн, который позволяет повторно использовать объекты вместо создания новых. Это может быть полезно в ситуациях, когда инициализация объектов затратна. Паттерн широко применяется в разработке игр и приложениях, где важно минимизировать использование памяти. В этой статье мы рассмотрим, как этот шаблон реализован в C#, и как он может улучшить производительность.
Object Pools in C#: Examples, Internals and Performance Benchmarks
Object Pool is a design pattern that allows reusing objects instead of creating new ones. This can be very useful in scenarios where object initialization is expensive. It is widely used, especially in game development and applications where low memory usage is critically important. In this article, we will look at how this pattern is implemented in C# and how it can improve performance.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Последние пару недель был занят, поэтому делюсь интересными материалами с адвента сразу за этот период. Вот три статьи, которые меня особенно зацепили. Полный список публикаций можно найти здесь.
В .NET 9 появился гибридный кэш, объединяющий преимущества локального и распределённого кэшей. Локальный кэш доступен в рамках одного процесса, а распределённый - нескольким процессам или серверам. Гибридный кэш сочетает плюсы обоих. В статье объясняется базовая настройка, а для детального изучения можно обратиться к документации Microsoft.
Мутационное тестирование - это способ проверки тестов. Суть в том, что исходный код подвергается небольшим изменениям, называемым "мутантами". Если после изменений тесты не ломаются, значит они недостаточно надёжны. В статье рассматривается библиотека Stryker (отсылка к X-Men?), которая позволяет делать мутационное тестирование C# программ.
Рассказ о том, как разработчик С# оптимизировал метод IEnumerable<T>.Sum с помощью векторизации. Эти изменения оказались полезными и его пул-реквест был принят в репозиторий .NET. Хороший пример, как умение писать высокопроизводительный код может пригодиться в жизни.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
В конце прошлого года на этом канале было 19 человек. Сейчас 174. Это же целая аудитория в университете! Круто, что меня читает так много инженеров. Спасибо вам за интерес и поддержку в течение этого года.
За год было написано много статей, большая часть которых публиковалась здесь. Полноценные статьи также выходили на Хабре, а переводы на Reddit. Часть из них была высоко оценена сообществом. Например, статью про FrozenDictionary репостили многие каналы и разбирали на подкасте DotNetRu.
Моя цель — сделать канал ещё полезнее для инженеров, продолжить обсуждать сложные темы простым языком. Буду рад вашим идеям и пожеланиям.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29
🇷🇸 Жизнь в Сербии. Часть 1. Стоимость жизни.
Давно хотел рассказать про жизнь в Сербии, поэтому начнём этот год с нетехнической статьи.
Предыстория
В Сербию мы впервые приехали в августе 2022 года. Тогда я ещё работал на проекте Fujitsu. Мы обеспечивали работу приложений в Японии, Южной Корее и Австралии. На тот момент серьёзно ходили слухи об отключении России от глобального интернета. Поскольку компания должна была обеспечивать непрерывную поддержку сервисов, инженеров периодически направляли в офис в Сербии. В августе пришла очередь и до меня. После этого было короткое возвращение на Родину, месячная командировка в Индию, смена работы и окончательный переезд в Сербию в октябре 2022 года.
Жильё
Мы снимаем «евродвушку» площадью 45 кв.м. за 650 € в месяц. Это медианная цена для района Новый Белград. Знаю людей, которые находили квартиры чуть больше за те же деньги, а также тех, кто платил значительно больше за аналогичное жильё. Кстати, понятие «евродвушка» в Сербии отсутствует — такие квартиры считаются однокомнатными.
Коммунальные услуги
Стоимость коммунальных услуг сильно зависит от сезона. Зима здесь мягкая, но отопление всё равно необходимо — оно составляет добрую половину платежа. Например, в декабре 2024 года отопление обошлось в 50 €. Летом же стоимость высока из-за кондиционера, так как 40-градусная жара в июле и августе — обычное явление в Белграде. Средняя стоимость коммуналки за последний год составила 97 €.
Связь
Интернет в квартире обходится в 14 € в месяц, при этом скорость составляет 500 Мбит/с. Мобильная связь в среднем стоит около 10 € на человека.
Транспорт
С 1 января 2025 года общественный транспорт в Белграде стал бесплатным. До этого единый безлимитный проездной на автобусы, троллейбусы и трамваи стоил около 19 € в месяц (2200 динар).
Такси я использую редко — за весь прошлый год было всего шесть поездок, каждая обошлась от 5 € до 22 €.
Продукты
Большую часть продуктов мы покупаем в супермаркетах Lidl, поэтому подсчитать расходы было просто — я просто сложил все чеки из приложения. Средний месячный расход на продукты за 2024 год составил около 300 €.
Медицина
Медицина в Сербии делится на государственную и частную. Государственная медицина практически бесплатная — за приём врача нужно заплатить около 0.5 €.
Частная медицина дороже. Без страховки на приём врача лучше заложить 50 €. Если потребуется диагностика, например УЗИ или МРТ, то стоимость может увеличиться до 100–200 €.
Итог
Сложим основные ежемесячные расходы:
- Аренда: 650 €
- Коммунальные услуги: 90 €
- Интернет: 14 €
- Мобильная связь (на двоих): 20 €
- Продукты: 300 €
Итоговая сумма: 1074 € в месяц
Эта цифра включает только базовые траты и может варьироваться в зависимости от личных потребностей и стиля жизни. В следующих частях я расскажу про другие аспекты жизни в Сербии.
Давно хотел рассказать про жизнь в Сербии, поэтому начнём этот год с нетехнической статьи.
Предыстория
В Сербию мы впервые приехали в августе 2022 года. Тогда я ещё работал на проекте Fujitsu. Мы обеспечивали работу приложений в Японии, Южной Корее и Австралии. На тот момент серьёзно ходили слухи об отключении России от глобального интернета. Поскольку компания должна была обеспечивать непрерывную поддержку сервисов, инженеров периодически направляли в офис в Сербии. В августе пришла очередь и до меня. После этого было короткое возвращение на Родину, месячная командировка в Индию, смена работы и окончательный переезд в Сербию в октябре 2022 года.
Жильё
Мы снимаем «евродвушку» площадью 45 кв.м. за 650 € в месяц. Это медианная цена для района Новый Белград. Знаю людей, которые находили квартиры чуть больше за те же деньги, а также тех, кто платил значительно больше за аналогичное жильё. Кстати, понятие «евродвушка» в Сербии отсутствует — такие квартиры считаются однокомнатными.
Коммунальные услуги
Стоимость коммунальных услуг сильно зависит от сезона. Зима здесь мягкая, но отопление всё равно необходимо — оно составляет добрую половину платежа. Например, в декабре 2024 года отопление обошлось в 50 €. Летом же стоимость высока из-за кондиционера, так как 40-градусная жара в июле и августе — обычное явление в Белграде. Средняя стоимость коммуналки за последний год составила 97 €.
Связь
Интернет в квартире обходится в 14 € в месяц, при этом скорость составляет 500 Мбит/с. Мобильная связь в среднем стоит около 10 € на человека.
Транспорт
С 1 января 2025 года общественный транспорт в Белграде стал бесплатным. До этого единый безлимитный проездной на автобусы, троллейбусы и трамваи стоил около 19 € в месяц (2200 динар).
Такси я использую редко — за весь прошлый год было всего шесть поездок, каждая обошлась от 5 € до 22 €.
Продукты
Большую часть продуктов мы покупаем в супермаркетах Lidl, поэтому подсчитать расходы было просто — я просто сложил все чеки из приложения. Средний месячный расход на продукты за 2024 год составил около 300 €.
Медицина
Медицина в Сербии делится на государственную и частную. Государственная медицина практически бесплатная — за приём врача нужно заплатить около 0.5 €.
Частная медицина дороже. Без страховки на приём врача лучше заложить 50 €. Если потребуется диагностика, например УЗИ или МРТ, то стоимость может увеличиться до 100–200 €.
Итог
Сложим основные ежемесячные расходы:
- Аренда: 650 €
- Коммунальные услуги: 90 €
- Интернет: 14 €
- Мобильная связь (на двоих): 20 €
- Продукты: 300 €
Итоговая сумма: 1074 € в месяц
Эта цифра включает только базовые траты и может варьироваться в зависимости от личных потребностей и стиля жизни. В следующих частях я расскажу про другие аспекты жизни в Сербии.
👍15
Сообщество DotNetRu на подкасте разбирает статью про пулы объектов в C#
Сегодня ребята из DotNetRu выложили подкаст, на котором разобрали мою статью про паттерн ObjectPool.
Если вы пропустили эту статью и вам интересен формат подкаста, то вот ссылка.
Сегодня ребята из DotNetRu выложили подкаст, на котором разобрали мою статью про паттерн ObjectPool.
Если вы пропустили эту статью и вам интересен формат подкаста, то вот ссылка.
Telegram
DotNetRu
Пулы объектов в деталях, невольный null в F#, весёлые ошибки в топе
Подкаст RadioDotNet выпуск №108 от 3 февраля 2025 года
https://radiodotnet.mave.digital/ep-109
Темы:
[00:01:45] — Пулы объектов в C#
• https://habr.com/ru/articles/864902/
[00:22:10]…
Подкаст RadioDotNet выпуск №108 от 3 февраля 2025 года
https://radiodotnet.mave.digital/ep-109
Темы:
[00:01:45] — Пулы объектов в C#
• https://habr.com/ru/articles/864902/
[00:22:10]…
👍9
Оптимизация JIT-компилятора при работе с коллекциями
Помните я писал статью про производительность foreach при работе с коллекциями через интерфейс IEnumerable?
Вкратце напомню в чём дело. Когда мы используем, например массивы и списки через интерфейс IEnumerable<T>, то их энумератор приводится к интерфейсу IEnumerator. У массивов и списков энумератор – это структура. Следовательно, при приведении происходит упаковка.
Так вот, команда .NET собирается добавить в .NET 10 оптимизацию для таких случаев, по крайней мере для массивов.
По моему, это круто. Теоретически, работа с массивами через LINQ должна ускориться. Будет интересно проверить этот функционал, когда появится первый релиз .NET 10.
Помните я писал статью про производительность foreach при работе с коллекциями через интерфейс IEnumerable?
Вкратце напомню в чём дело. Когда мы используем, например массивы и списки через интерфейс IEnumerable<T>, то их энумератор приводится к интерфейсу IEnumerator. У массивов и списков энумератор – это структура. Следовательно, при приведении происходит упаковка.
Так вот, команда .NET собирается добавить в .NET 10 оптимизацию для таких случаев, по крайней мере для массивов.
По моему, это круто. Теоретически, работа с массивами через LINQ должна ускориться. Будет интересно проверить этот функционал, когда появится первый релиз .NET 10.
Telegram
yet another dev
👩💻 Пишем производительный C# код при работе с коллекциями
Публикую следующую часть статьи про производительность коллекций. Сегодня про Enumerator.
---
Предположим, у нас есть массив _transactionsArray и список _transactionsList. Сама транзакция выглядит…
Публикую следующую часть статьи про производительность коллекций. Сегодня про Enumerator.
---
Предположим, у нас есть массив _transactionsArray и список _transactionsList. Сама транзакция выглядит…
👍7
FluentAssertions стала платной
Коллеги, если вы вдруг пропустили новость, то сообщаю. Библиотека для тестирования FluentAssertions стала платной около месяца назад. Теперь стандартная лицензия для 1 разработчика стоит $129.95 в год, а для небольших компаний – $49.95 в год.
Новость довольно неприятная. Мы, например, используем её повсеместно на наших проектах.
Какие есть альтернативы:
1. Остаться на FluentAssertions не выше версии 7.0.0.
2. Перейти на AwesomeAssertions – форк FluentAssertions с лицензией Apache 2.0, который продолжит развиваться сообществом.
3. Перейти на Shouldly – бесплатную библиотеку с лицензией BSD.
4. Перейти на NFluent – ещё одну бесплатную библиотеку.
5. Вернуться к классическому Assert.
Если вы уже используете FluentAssertions, самым простым вариантом будет переход на AwesomeAssertions.
Коллеги, если вы вдруг пропустили новость, то сообщаю. Библиотека для тестирования FluentAssertions стала платной около месяца назад. Теперь стандартная лицензия для 1 разработчика стоит $129.95 в год, а для небольших компаний – $49.95 в год.
Новость довольно неприятная. Мы, например, используем её повсеместно на наших проектах.
Какие есть альтернативы:
1. Остаться на FluentAssertions не выше версии 7.0.0.
2. Перейти на AwesomeAssertions – форк FluentAssertions с лицензией Apache 2.0, который продолжит развиваться сообществом.
3. Перейти на Shouldly – бесплатную библиотеку с лицензией BSD.
4. Перейти на NFluent – ещё одну бесплатную библиотеку.
5. Вернуться к классическому Assert.
Если вы уже используете FluentAssertions, самым простым вариантом будет переход на AwesomeAssertions.
👍11