Комментарии 11
Но я периодически делюсь подобными техническими тонкостями в коротких постах на своём Telegram-канале, поскольку формат Habr не всегда подходит для этого.
На Хабре уже больше года как заведён раздел «Посты», который буквально для таких коротких (до 1500 символов) публикаций и предназначен.
А в «Телеграме» у меня чат с мамой. С моей точки зрения, «Телеграм» для чтения и ведения блогов абсолютно не предназначен. Публикация в «Телеграме» выглядит как сообщение, нет возможности чередовать текст и изображения, есть куча разных ограничений, отсутствует РСС.
Зачем заводить и вести айтишные блоги в мессенджере, который ещё непонятно как индексируется поисковиками — загадка. С таким же успехом можно пытаться делиться опытом в «Снэпчате» или просить подписаться на аккаунт в «ТикТоке». Для меня каналы в «Телеграме» выглядят как очередное коллективное помешательство.
Посмотрел функционал постов на Хабре. Не получается прикрепить больше одной картинки. Даже короткий пост про один простой бенчмарк требует поясняющих диаграмм, одного или нескольких графиков. В Telegram можно прикрепить до 10 картинок в сообщении. Но вы натолкнули на идею, что можно попробовать всё скомпоновать в одну картинку. Я попробую, спасибо.
Статья хорошая, автору спасибо!
С моей точки зрения, «Телеграм» для чтения и ведения блогов
Посты на Хабре для этого ещё менее пригодны - монетизации нет или хромает, кол-во просмотров не очень, возможно реклама запрещена, ну и другие ограничения (возможно ошибаюсь по этим пунктам, может кто меня поправит - в Посты не вникал) - не очень удобно так блоггером работать. Сам не блоггер, посты не постил и в них не хожу могу ошибаться, просто пытаюсь смотреть на вещи непредвзято со стороны обоих сторон.
Навязчивая реклама блогов на Хабре с пустыми статьями от ИИ раздражает, а ненавязчивая ссылка под хорошей статьей - вполне себе приемлемо, как по мне.
Честно не сильно хотел подробно вникать в принципы работы алгоритмов поиска, но как результат, что и при каких условиях быстрее работает, было интересно почитать)
Подскажите, в какой программе сделаны иллюстрации схем к статье?
Диаграммы создаю в app.diagrams.net. Графики рисую в colab.research.google.com через matplotlib, либо через datawrapper.de.
Гм, а у меня на данных в полмиллиона ссылочных значений и с ключом в виде короткой (до 10 символов) строки изменяемой длины разницы по производительности между обычным словарем и замороженным не было, а вот immutable dictionary очень сильно медленнее был обоих. Проверял на .NET 8.0
Immutable Dictionary это вообще очень специфичная структура данных. Она не Frozen, есть операции изменения, но при этом каждое изменение создаёт новый Immutable Dictionary. А в старых обьектах остаются те же самые значения.
Чтобы такое было возможно, их сделали на базе деревьев, а не хеш-таблицы. Соответственно стоимость поиска ключа и стоимость изменения - O(logN), в отличие от O(1) у Dictionary и FrozenDictionary.
Для 500k элементов разницы действительно может не быть. В моём бенчмарке при 100k элементах и строке в виде GUID скорость поиска FrozenDictionary была хуже Dictionary. Чтобы понять, почему у вас именно так, нужно посмотреть какой тип словаря был выбран. Возможно OrdinalStringFrozenDictionary_Full. В нём расчёт хэша происходит по полной строке.
А можете сравнить с SortedDictionary?
Заглядываем под капот FrozenDictionary: насколько он быстрее Dictionary и почему