Да зря вы так, охотно поверю. Я встречал много людей, который приобрели эти знания и опыт другим путём. Мой рассказ о том, что этот опыт можно получить и через Олимпиады тоже.
Возможно, процесс разработки и качество продукта у вас таковы, что не допускают других решений. Я же видел множество обратных примеров. А порой, даже сложно аргументировать, почему хэшсет будет лучше массива, потому что это никак не отражается на пользователе, бизнесе. Но лично для меня такие микро-оптимизации на всех уровнях потом складываются в более устойчивое решение.
Не знаю, опять повторюсь, что от меня ускользает суть спора. Но какое-то сомнительное отношение к бывшим олимпиадникам всё таки чувствую, о чем изначально и писал.
Еще раз. Олимпиадник концентрируется на короткое время на небольшой изолированной задаче. Бизнес-разработчик концентрируется длительное время на большой задаче и должен держать в голове десятки тысяч строк кода.
Наверное, тут имеется ввиду, что олимпиадник концентрируется на короткое время на олимпиаде. Я как олимпиадник концентрируюсь на длительное время на большой задаче (от года и более) в работе. Я ж всё таки понимаю, что это разные задачи.
Но, например, мне как олимпиаднику, на каком-то интуитивном уровне понятно, почему стоит использовать HashSet в некоторых местах, не допускать проблем N+1 запроса на ровном месте, как устроен индекс в БД и порядок полей в нём важен.
Я немного потерял, в чем суть противоречия. В том, что олимпиадные задачи - это не рабочие задачи? Ну так да, это факт. Вроде все (подавляющее большинство) с этим согласны.
Если дальше проводить спортивные аналогии, то хоккеисты ходят в зал, крутят велосипед, бегают кроссы - это вообще не то, чем они занимаются в "работе" на площадке. Но эта разминка помогает им держать себя к форме. Так и с олимпиадами. Какой-то опыт участия помогает прокачать те самые "мышцы" в голове, которые потом могут быть полезны в работе. И не потому, что там будут точно такие же задачи, а потому что там будут какие-то похожие базовые нагрузки, требования.
Мне понравилась ваша аналогия про спорт и бегунов. Я в своей статье приводил аналогию со спортом, но, видимо, недостаточно хорошо получилось. Глубже не стал расписывать, чтобы не было слишком занудно. А у вас получилось достаточно хорошо.
Да, это осознанно "опыт + инструмент": я описываю конкретную проблему, в которую сам много раз упирался (да и мои коллеги тоже), и показываю путь, который прошёл до решения.
Понятно, что ради этого плагина нет смыслы заносить в проект AutoMapper. Но раз он уже есть, то можно попытаться облегчить себе жизнь.
Статья о том, когда этот швейцарский нож уже воткнули вам в проект и теперь как-то надо с ним жить. Mapster/Mapperly/ещё кто‑то действительно комфортнее по DX и производительности. Но там, где AutoMapper уже накопил сотни CreateMap, может быть проще сначала научиться хотя бы нормально по ним ходить, а потом уже планировать миграцию на что‑то более современное.
Полностью согласен, что source‑generator мапперы (Mapperly и т.п.) куда приятнее AutoMapper — явный код, нормальная навигация, никакой рефлексии.
Этот плагин как раз для "тёмной реальности", где AutoMapper уже живёт в большом легаси и выкинуть его за неделю невозможно. Пока проект постепенно мигрирует (на Mapperly или что угодно ещё), разработчикам всё равно приходится отвечать на вопрос "откуда это значение взялось?" - и тут FindUsage по маппингам спасает нервы.
Но чтобы такие профессионалы появлялись в индустрии, им сначала нужно дорастать до этого уровня, и на это требуется время.
Ваш комментарий выглядит так, будто должен заставить комплексовать разработчиков, которые не знали о такой возможности. Появление профессионалов требует спокойных разборов базовых тем, а не стыда за незнание.
Мои статьи для всех. Я показываю простые примеры оптимизаций, на которые обычно забивают и считают их незначительными. Я рассказываю реальную историю о том, где это пригодилось. И для меня важно, чтобы после статьи человек посмотрел на свой проект и нашёл очевидные возможности для улучшений.
Ну что сказать, могу только порадоваться за такие высокие ожидания от Контура в плане технических статей. Что-то более зубодробительное обычно пишет мой коллега, его статьи тоже есть в блоге. Там действительно часть разбираются какие-то хитрые кейсы.
Если говорить про себя, то я как-то уже писал, что мне нравятся такие простые (можно сказать "дешевые") оптимизации, которые будут полезны в любом проекте. И, мне кажется, с таких примеров легче заинтересовать разработчиков поглубже изучить язык, на котором они работают. Ведь действительно, всё так просто, нужно только указать Capacity. Из таких мелочей складывается понимание того, как работает твой код.
В любом случае, спасибо вам за оценку, я продолжу искать что-нибудь интересное для Хабра. А что-то более специфичное оседает у меня в блоге.
Строки в C# иммутабельны, поэтому менять существующую строку не получится. Есть, конечно, вариант сразу создать строку нужной длины и проинициализировать её только символами без пробелов - примерно так и делает реализация регулярных выражений. Именно поэтому там всего 64 байта памяти в бенчмарке.
Еще виновата лямбда c => !char.IsWhiteSpace(c). Она разворачивается в не самую простую конструкцию и тоже занимает немного места. Поэтому в критичных местах LINQ является проблемой.
LINQ умеет в ленивые вычисления. Метод Where - ленивый, а вот уже ToArray() - материализация коллекции. Т.к. конструктор строки требует массив, то приходится его вызывать.
Не совсем понимаю, что вы имеете ввиду. Если использовать int.TryParse на всей строке, то как я сказал, такой вариант нам не подходит из-за ведущих нолей и общей длины строки.
Если использовать int.TryParse на каждом отдельном символе строки, то это будет намного медленнее, т.к. придется преобразовывать каждый символ в строку, потом его парсить.
Во многих случаях хранение таких данных как чисел невозможно. Например,трудно отличать значение 00123 от 123. Так же, какой-нибудь номер банковской карты не влезает в стандартные числовые типы данных, поэтому это всё хранится как строка. И тогда важно уметь валидировать входные данные без преобразований.
Да зря вы так, охотно поверю. Я встречал много людей, который приобрели эти знания и опыт другим путём. Мой рассказ о том, что этот опыт можно получить и через Олимпиады тоже.
Возможно, процесс разработки и качество продукта у вас таковы, что не допускают других решений. Я же видел множество обратных примеров. А порой, даже сложно аргументировать, почему хэшсет будет лучше массива, потому что это никак не отражается на пользователе, бизнесе. Но лично для меня такие микро-оптимизации на всех уровнях потом складываются в более устойчивое решение.
Не знаю, опять повторюсь, что от меня ускользает суть спора. Но какое-то сомнительное отношение к бывшим олимпиадникам всё таки чувствую, о чем изначально и писал.
Наверное, тут имеется ввиду, что олимпиадник концентрируется на короткое время на олимпиаде. Я как олимпиадник концентрируюсь на длительное время на большой задаче (от года и более) в работе. Я ж всё таки понимаю, что это разные задачи.
Но, например, мне как олимпиаднику, на каком-то интуитивном уровне понятно, почему стоит использовать HashSet в некоторых местах, не допускать проблем N+1 запроса на ровном месте, как устроен индекс в БД и порядок полей в нём важен.
Я немного потерял, в чем суть противоречия. В том, что олимпиадные задачи - это не рабочие задачи? Ну так да, это факт. Вроде все (подавляющее большинство) с этим согласны.
Если дальше проводить спортивные аналогии, то хоккеисты ходят в зал, крутят велосипед, бегают кроссы - это вообще не то, чем они занимаются в "работе" на площадке. Но эта разминка помогает им держать себя к форме.
Так и с олимпиадами. Какой-то опыт участия помогает прокачать те самые "мышцы" в голове, которые потом могут быть полезны в работе. И не потому, что там будут точно такие же задачи, а потому что там будут какие-то похожие базовые нагрузки, требования.
Мне понравилась ваша аналогия про спорт и бегунов. Я в своей статье приводил аналогию со спортом, но, видимо, недостаточно хорошо получилось. Глубже не стал расписывать, чтобы не было слишком занудно. А у вас получилось достаточно хорошо.
Да, это осознанно "опыт + инструмент": я описываю конкретную проблему, в которую сам много раз упирался (да и мои коллеги тоже), и показываю путь, который прошёл до решения.
Понятно, что ради этого плагина нет смыслы заносить в проект AutoMapper. Но раз он уже есть, то можно попытаться облегчить себе жизнь.
Статья о том, когда этот швейцарский нож уже воткнули вам в проект и теперь как-то надо с ним жить. Mapster/Mapperly/ещё кто‑то действительно комфортнее по DX и производительности. Но там, где AutoMapper уже накопил сотни
CreateMap, может быть проще сначала научиться хотя бы нормально по ним ходить, а потом уже планировать миграцию на что‑то более современное.Полностью согласен, что source‑generator мапперы (Mapperly и т.п.) куда приятнее AutoMapper — явный код, нормальная навигация, никакой рефлексии.
Этот плагин как раз для "тёмной реальности", где AutoMapper уже живёт в большом легаси и выкинуть его за неделю невозможно. Пока проект постепенно мигрирует (на Mapperly или что угодно ещё), разработчикам всё равно приходится отвечать на вопрос "откуда это значение взялось?" - и тут FindUsage по маппингам спасает нервы.
Спасибо, старался в этот раз поглубже залезть.
Наш любимый BenchmarkDotNet может достать asm-код, если навесить атрибут
DisassemblyDiagnoser.Можете заметить, что он есть в исходном коде бенчмарка.
Согласен, профессионал должен знать возможности своего инструмента.
Но чтобы такие профессионалы появлялись в индустрии, им сначала нужно дорастать до этого уровня, и на это требуется время.
Ваш комментарий выглядит так, будто должен заставить комплексовать разработчиков, которые не знали о такой возможности. Появление профессионалов требует спокойных разборов базовых тем, а не стыда за незнание.
Мои статьи для всех. Я показываю простые примеры оптимизаций, на которые обычно забивают и считают их незначительными. Я рассказываю реальную историю о том, где это пригодилось. И для меня важно, чтобы после статьи человек посмотрел на свой проект и нашёл очевидные возможности для улучшений.
Решил оставить как есть, пусть комментарии дополняют исходную статью и будут отдельным источник знаний.
По Imutable и Frozen есть пара интересных статей:
Заглядываем под капот FrozenDictionary: насколько он быстрее Dictionary и почему
Самый простой и подробный гайд по конкурентным коллекциям в C#
Поэтому тут я не стал повторяться.
Ну что сказать, могу только порадоваться за такие высокие ожидания от Контура в плане технических статей. Что-то более зубодробительное обычно пишет мой коллега, его статьи тоже есть в блоге. Там действительно часть разбираются какие-то хитрые кейсы.
Если говорить про себя, то я как-то уже писал, что мне нравятся такие простые (можно сказать "дешевые") оптимизации, которые будут полезны в любом проекте. И, мне кажется, с таких примеров легче заинтересовать разработчиков поглубже изучить язык, на котором они работают. Ведь действительно, всё так просто, нужно только указать Capacity. Из таких мелочей складывается понимание того, как работает твой код.
В любом случае, спасибо вам за оценку, я продолжу искать что-нибудь интересное для Хабра. А что-то более специфичное оседает у меня в блоге.
Спасибо за дополнение. Бенчмарк с вами согласен и опять же говорит, что мы не тратим лишнюю память, ну и побыстрее это будет.
Строки в C# иммутабельны, поэтому менять существующую строку не получится.
Есть, конечно, вариант сразу создать строку нужной длины и проинициализировать её только символами без пробелов - примерно так и делает реализация регулярных выражений. Именно поэтому там всего 64 байта памяти в бенчмарке.
Действительно, важное замечание про размер стэка. Куда-то потерялся абзац про это, вернул его. Спасибо.
Еще виновата лямбда
c => !char.IsWhiteSpace(c).Она разворачивается в не самую простую конструкцию и тоже занимает немного места. Поэтому в критичных местах LINQ является проблемой.
LINQ умеет в ленивые вычисления. Метод
Where- ленивый, а вот ужеToArray()- материализация коллекции. Т.к. конструктор строки требует массив, то приходится его вызывать.Рассмотрел несколько вариантов: https://habr.com/ru/companies/skbkontur/articles/970178/
Так ведь цикл ни в каком бенчмарке не медленнее регулярного выражения (в рамках одного фреймворка). Реализация через цикл - одна из самых быстрых.
Не совсем понимаю, что вы имеете ввиду. Если использовать
int.TryParseна всей строке, то как я сказал, такой вариант нам не подходит из-за ведущих нолей и общей длины строки.Если использовать
int.TryParseна каждом отдельном символе строки, то это будет намного медленнее, т.к. придется преобразовывать каждый символ в строку, потом его парсить.Во многих случаях хранение таких данных как чисел невозможно. Например,трудно отличать значение
00123от123. Так же, какой-нибудь номер банковской карты не влезает в стандартные числовые типы данных, поэтому это всё хранится как строка. И тогда важно уметь валидировать входные данные без преобразований.