Я провел новое тестирование и исправил ошибку. Спасибо за Вашу внимательность. В Mapster_MapUserToDomain не применился конфиг маппинга поля Name. Сейчас память для всех 4 маппингов выравнилась, а время выполнения метода Adapt чуть возросло, но не превысило время AutoMapper. В скором времени я обновлю статью и эта правка попадет в нее.
Конечно! Думаю, я смогу опубликовать проект, но сначала хотел бы проверить вариант, что при маппинге через мапстер Adapt не сработали правила преобразования. В этом случае нужно будет обновить результаты Mapster_MapUserToDomain
Да, вопрос интересный, обязательно проверю. Возможно, Вы правы и ответ в реализации конкатинации строк FName и LName. Еще думаю есть вариант, что банально при маппинге через мапстер в тесте не сработали правила перевода конвертации Name, и этих преобразований вообще не было. В любом случае я добавлю к статье полученные результаты после перепроверки
Сейчас однозначно сказать не могу. Сам метод Adapt<TDest> в Mapster работает через LambdaExpression с дальнейшим его хэшированием и переиспользованием. Возможно, тут удается избежать лишнего выделения памяти, но странно, что получилась такая большая разница с маппингами других типов. Думаю, я смогу провести повторное тестирование и дать ответ позднее
Добрый день! В целом существенных различий между маппингами других моделей и модели User из примера - нет. На сколько я понимаю, Вы хотите сказать, что вызов Extension метода Adapt в некоторых случаях будет работать не хуже сгенерированного метода. С этим я согласен, и в некоторых тестах я это наблюдал. Однако в целом сгенерированные методы в большинстве случаев работают чуть быстрее. Проблема в том, что тестировать мапперы на каждую модель и выбирать оптимальный вариант - долго и дорого. Я хотел дать некоторый универсальный способ, который подойдет в большинстве случаев для решения данной проблемы.
Я провел новое тестирование и исправил ошибку. Спасибо за Вашу внимательность. В Mapster_MapUserToDomain не применился конфиг маппинга поля Name. Сейчас память для всех 4 маппингов выравнилась, а время выполнения метода Adapt чуть возросло, но не превысило время AutoMapper. В скором времени я обновлю статью и эта правка попадет в нее.
Конечно! Думаю, я смогу опубликовать проект, но сначала хотел бы проверить вариант, что при маппинге через мапстер Adapt не сработали правила преобразования. В этом случае нужно будет обновить результаты Mapster_MapUserToDomain
Да, вопрос интересный, обязательно проверю. Возможно, Вы правы и ответ в реализации конкатинации строк FName и LName. Еще думаю есть вариант, что банально при маппинге через мапстер в тесте не сработали правила перевода конвертации Name, и этих преобразований вообще не было. В любом случае я добавлю к статье полученные результаты после перепроверки
Сейчас однозначно сказать не могу. Сам метод Adapt<TDest> в Mapster работает через LambdaExpression с дальнейшим его хэшированием и переиспользованием. Возможно, тут удается избежать лишнего выделения памяти, но странно, что получилась такая большая разница с маппингами других типов. Думаю, я смогу провести повторное тестирование и дать ответ позднее
Добрый день! В целом существенных различий между маппингами других моделей и модели User из примера - нет. На сколько я понимаю, Вы хотите сказать, что вызов Extension метода Adapt в некоторых случаях будет работать не хуже сгенерированного метода. С этим я согласен, и в некоторых тестах я это наблюдал. Однако в целом сгенерированные методы в большинстве случаев работают чуть быстрее. Проблема в том, что тестировать мапперы на каждую модель и выбирать оптимальный вариант - долго и дорого. Я хотел дать некоторый универсальный способ, который подойдет в большинстве случаев для решения данной проблемы.