Я думаю, вы найдёте ответы на большинство ваших вопросов в книге Pro .NET Benchmarking. Там и про влияние железа на бенчмарки, и про влияние компиляторов и их алгоритмы оптимизации, и про то, как вообще правильно делать измерения. Рекомендую ознакомиться :)
Для 500k элементов разницы действительно может не быть. В моём бенчмарке при 100k элементах и строке в виде GUID скорость поиска FrozenDictionary была хуже Dictionary. Чтобы понять, почему у вас именно так, нужно посмотреть какой тип словаря был выбран. Возможно OrdinalStringFrozenDictionary_Full. В нём расчёт хэша происходит по полной строке.
Посмотрел функционал постов на Хабре. Не получается прикрепить больше одной картинки. Даже короткий пост про один простой бенчмарк требует поясняющих диаграмм, одного или нескольких графиков. В Telegram можно прикрепить до 10 картинок в сообщении. Но вы натолкнули на идею, что можно попробовать всё скомпоновать в одну картинку. Я попробую, спасибо.
Довольно очевидный, и старый способ вертикально подняться, разве нет?
Если честно, то мне не показалось очевидно. И насчёт старого способа я не уверен. Есть примеры из прошлого?
Вообще, вся схема кажется нежизнеспособной по одной причине. У Минцифры уже давно есть свой "профсоюз". Называется МИТ. Тока они предусмотрительно назвали его "ассоциацией работников, инвесторов и компаний". Там как раз Шадаев и председательствует. И они без этого "профсоюза работников it" протолкнут всё что надо протолкнуть.
Нет, это не точно. Пока не сделать конкретные замеры и не показать результаты, нельзя сказать, что один подход быстрее другого. И то, результаты будут валидны с определёнными оговорками. Так что пока мы можем только теоретически рассуждать, что мы и делаем. :)
По поводу FrozenDictionary вы правы, работает быстрее.
| Method | Categories | Repeats | Mean | Error | StdDev | Gen0 | Gen1 | Gen2 | Allocated |
|----------------------------- |----------- |-------- |---------:|---------:|---------:|---------:|---------:|---------:|----------:|
| FrozenDictionary | Class | 100000 | 24.23 ms | 0.327 ms | 0.376 ms | 437.5000 | 437.5000 | 437.5000 | 7.29 MB |
| Dictionary | Struct | 100000 | 69.79 ms | 1.072 ms | 1.235 ms | 375.0000 | 375.0000 | 375.0000 | 4.14 MB |
| DictionaryCollectionsMarshal | Struct | 100000 | 34.22 ms | 2.077 ms | 2.392 ms | 428.5714 | 428.5714 | 428.5714 | 4.14 MB |
Опять же, выбор будет зависеть от сценария. Если создавать словарь нужно относительно редко (т.е. аллоцировать память для экземпляров классов), то это хорошее решение. Если же, например, на каждый запрос нужно достать из БД какие-то данные, преобразовать в словарь, потом осуществить поиск, то структуры + CollectionsMarshall, думаю, будут быстрее.
Да, есть небольшой выигрыш за счёт того, что ссылки не считаются и ансейф во все поля
Вы сами ответили на вопрос. :)
Если рассматривать только то, что приведено в статье, то да, выигрыш небольшой. Если смотреть шире, как структуры влияют на всё приложение, то за счёт их использования можно ускорить работу и снизить потребление памяти. Данные в массиве data из примера же не берутся из воздуха. CLR в какой-то момент времени 100 000 аллоцировала память под 100 000 экземпляров классов + 1 раз для словаря. В случае со структурами, аллокация произошла только для словаря. Что быстрее: аллоцировать 100 001 раз память в куче или всего 1 раз? Но, опять же, всё зависит от сценария. Я не утверждаю, что рассмотренный мною способ единственно правильный.
Да, вы правы. В аналогичном сценарии Span даже работал чуть медленнее. Но если не вызывать ToString, то естественно Span быстрее.
На самом деле про Span статья уже давно есть, правда она на английском. И писалась она мной до того, как прочитал книгу про бенчмарки. Так что возможно там есть какие-то ошибки в замерах и я хотел сделать ревью перед публикацией на Хабр.
По поводу сравнения со StringBuilder. Какие именно сценарии интересуют? Вариантов просто может быть масса :)
Ах, если бы люди умели читать, то в мире бы давно наступил коммунизм. )) Статья о том, что рассмотренные выше способыя встречал на практике. Это не значит, что это правильно или так надо делать. Это значит, что такой код пишут люди. Люди, например, берут split, разбивают по символу и берут последнее/первое/любое другое вхождение. С точки зрения результата выходит то же самое - извлечена нужна подстрока. Поэтому и сравниваю.
непонятно почему они поддерживают только абсолютные пути
Потому что фейковые данные для примера сгенерированы именно в таком формате. Проверить всевозможные варианты записи путей не было задачей.
Мир был бы прекрасен, если бы все разработчики были такими как вы и знали как пользоваться инструментами. :) Но, к сожалению, приходится видеть код, который я и разбирал в статье. А значит понятно не всем. Хотелось наглядно показать, особенно начинающим специалистам, почему не надо использовать газонокосилку, где нужен скальпель.
Я думаю, вы найдёте ответы на большинство ваших вопросов в книге Pro .NET Benchmarking. Там и про влияние железа на бенчмарки, и про влияние компиляторов и их алгоритмы оптимизации, и про то, как вообще правильно делать измерения. Рекомендую ознакомиться :)
Могу. Добавлю в список идей. :)
Для 500k элементов разницы действительно может не быть. В моём бенчмарке при 100k элементах и строке в виде GUID скорость поиска FrozenDictionary была хуже Dictionary. Чтобы понять, почему у вас именно так, нужно посмотреть какой тип словаря был выбран. Возможно OrdinalStringFrozenDictionary_Full. В нём расчёт хэша происходит по полной строке.
Диаграммы создаю в app.diagrams.net. Графики рисую в colab.research.google.com через matplotlib, либо через datawrapper.de.
Посмотрел функционал постов на Хабре. Не получается прикрепить больше одной картинки. Даже короткий пост про один простой бенчмарк требует поясняющих диаграмм, одного или нескольких графиков. В Telegram можно прикрепить до 10 картинок в сообщении. Но вы натолкнули на идею, что можно попробовать всё скомпоновать в одну картинку. Я попробую, спасибо.
Если честно, то мне не показалось очевидно. И насчёт старого способа я не уверен. Есть примеры из прошлого?
Вообще, вся схема кажется нежизнеспособной по одной причине. У Минцифры уже давно есть свой "профсоюз". Называется МИТ. Тока они предусмотрительно назвали его "ассоциацией работников, инвесторов и компаний". Там как раз Шадаев и председательствует. И они без этого "профсоюза работников it" протолкнут всё что надо протолкнуть.
А как он по вашему работает?
Как много людей оказывается не читают статьи дальше заголовков
В решении дела, которе вы скинули, написано:
Super.web нарушила ТК и суд это установил. Какой там ответ они готовят? Не мы такие. Жизнь такая?
Случайно обнаружил вот это issue https://github.com/dotnet/runtime/issues/27062, когда гуглил как структуры подружить со словарём. :)
Нет, это не точно. Пока не сделать конкретные замеры и не показать результаты, нельзя сказать, что один подход быстрее другого. И то, результаты будут валидны с определёнными оговорками. Так что пока мы можем только теоретически рассуждать, что мы и делаем. :)
По поводу
FrozenDictionaryвы правы, работает быстрее.Опять же, выбор будет зависеть от сценария. Если создавать словарь нужно относительно редко (т.е. аллоцировать память для экземпляров классов), то это хорошее решение. Если же, например, на каждый запрос нужно достать из БД какие-то данные, преобразовать в словарь, потом осуществить поиск, то структуры + CollectionsMarshall, думаю, будут быстрее.
Вы сами ответили на вопрос. :)
Если рассматривать только то, что приведено в статье, то да, выигрыш небольшой. Если смотреть шире, как структуры влияют на всё приложение, то за счёт их использования можно ускорить работу и снизить потребление памяти. Данные в массиве data из примера же не берутся из воздуха. CLR в какой-то момент времени 100 000 аллоцировала память под 100 000 экземпляров классов + 1 раз для словаря. В случае со структурами, аллокация произошла только для словаря. Что быстрее: аллоцировать 100 001 раз память в куче или всего 1 раз? Но, опять же, всё зависит от сценария. Я не утверждаю, что рассмотренный мною способ единственно правильный.
А куда делись 10% штата?
Да, вы правы. В аналогичном сценарии Span даже работал чуть медленнее. Но если не вызывать ToString, то естественно Span быстрее.
На самом деле про Span статья уже давно есть, правда она на английском. И писалась она мной до того, как прочитал книгу про бенчмарки. Так что возможно там есть какие-то ошибки в замерах и я хотел сделать ревью перед публикацией на Хабр.
По поводу сравнения со StringBuilder. Какие именно сценарии интересуют? Вариантов просто может быть масса :)
Минцифры считает ИТ компанией. ?♂️
Ах, если бы люди умели читать, то в мире бы давно наступил коммунизм. )) Статья о том, что рассмотренные выше способы я встречал на практике. Это не значит, что это правильно или так надо делать. Это значит, что такой код пишут люди. Люди, например, берут split, разбивают по символу и берут последнее/первое/любое другое вхождение. С точки зрения результата выходит то же самое - извлечена нужна подстрока. Поэтому и сравниваю.
Потому что фейковые данные для примера сгенерированы именно в таком формате. Проверить всевозможные варианты записи путей не было задачей.
Отлично. )) Да, с LINQ вариантов масса. Такие способы ещё не доводилось на практике видеть (надеюсь и не придётся).
Мир был бы прекрасен, если бы все разработчики были такими как вы и знали как пользоваться инструментами. :) Но, к сожалению, приходится видеть код, который я и разбирал в статье. А значит понятно не всем. Хотелось наглядно показать, особенно начинающим специалистам, почему не надо использовать газонокосилку, где нужен скальпель.
Использовали. ? Про Span как-нибудь отдельно опубликую статью.