Как бы мы не пытались оптимизировать структуры данных и алгоритмы поиска, когда речь заходит о действительно больших массивах данных и действительно большом количестве запросов, необходимо задуматься о возможности повлиять на производительность системы путем увеличения аппаратного ресурса.
Не могли бы привести числа
Master-ноды отвечают за важные, но довольно легкие общекластерные действия. Это означает, что они требуют большого ресурса и высокой стабильности от физической ноды.
Если не затруднит,- внесите ясность
p.s. Ваша статья изобилует оценочными. Хотелось бы больше конкретики.
Большое спасибо за статью. Выражаю вам огромную поддержку за то, что не останавливаетесь и доводите дело если не до конца, то до стадии публикации и продвижения.
Не могли бы вы на пальцах пояснить эту математику?
В нашем примере с 4 байтами — 85К / (от 16 до 32 байт на поле * количество полей = 4) минус размер заголовка массива: примерно от 650 до 1300 элементов на массив в зависимости от платформы (а брать понятное дело надо в меньшую сторону). Всего-то! Не так и много! А ведь могло показаться что магическая константа в 1000 элементов вполне могла подойти!
В таком случае «маппер» для каждой пары типов у вас будет свой, а не хватать им будет ровно одной единственной функциональности-
ObjectBuilder.GetActivator<TSource, TDest>()
Ничего не имею против такого подхода, но в таком случае вам в качестве зависимостей нужен не столько маппер, сколько библиотека по компиляции плана создания экземпляра требуемого типа.
Совершенно верно. Вероятно я ввёл читателей в заблуждение, однако, цели написать полноценный маппер не стояло (впрочем, даже если и так, то был выбран итеративный подход).
В первую очередь было интересно реализовать совершенно базовый функционал наиболее оптимальным способом.
Добавлю EmitMapper в сравнение и попробую FastExpressionCompiler. Спасибо.
А хранить `map` вы где будете и с каким ключём? :)
Это подходит для того случая, когда перед стоит задача сделать маппинг коллекции здесь и сейчас, однако, ровно такой же код может быть реализован в методе маппинга коллекций самого маппера:
Не могли бы привести числа
Если не затруднит,- внесите ясность
p.s. Ваша статья изобилует оценочными. Хотелось бы больше конкретики.
C# 1001 notes — Регулярные короткие заметки по C# и .NET.
Регулярные короткие заметки по C# и .NET: @csharp_1001_notes.
Есть ли в планах повторить эксперимент применимо к .NET Core?
2. Не совсем понял. Можно пояснения в виде кода?
В первую очередь было интересно реализовать совершенно базовый функционал наиболее оптимальным способом.
Добавлю EmitMapper в сравнение и попробую FastExpressionCompiler. Спасибо.
Это подходит для того случая, когда перед стоит задача сделать маппинг коллекции здесь и сейчас, однако, ровно такой же код может быть реализован в методе маппинга коллекций самого маппера: