在前两天遇到 .NET Core 中 EF Core 的异步与同步查询的百倍性能之差(详情之前的博文)之后,这两天又遇到了 AutoMapper ProjectTo<T>
与 Mapster ProjectToType<T>
的千倍性能之差。
问题是在昨天发现的,使用 AutoMapper ProjectTo<T> + EF Core
从数据库中获取20条记录竟然耗时 10s
左右。
[Information] Executed DbCommand ("9,947"ms) [Parameters=["@__p_3='20'"], CommandType='Text', CommandTimeout='30']"
如果改为获取10条记录,耗时需要 5s
左右,从中可以推测某个原因造成获取单条记录增加了额外的开销。
而用同样的 SQL 语句在 SSMS 中查询数据库飞快,可以排除不是数据库层面的问题。
根据前车之鉴,将异步的 ToListAsync()
改为同步的 ToList()
,但问题依旧。
对于这个奇怪的问题,从 EF Core 层面实在找不到线索,于是将怀疑的目光转向了 AutoMapper
。
代码中用到了 AutoMapper 的 ProjectTo
:
return await _postQueryRepository
.GetPostsByStartId(startId)
.OrderBy(p => p.Id)
.Take(itemCount)
.ProjectTo<T>()
.ToListAsync();
在配置映射时使用了字符串连接:
conf.CreateMap<BlogPost, BlogPostDto>()
.ForMember(dto => dto.AuthorUrl, opt => opt.MapFrom(p => "https://www.cnblogs.com/" + p.BlogSite.Application + "/"));
去掉上面的映射配置之后,速度立马变得飞快,而 Executed DbCommand
执行时间从 9,947ms
飞流直下 2ms
,原来是 AutoMapper 惹的祸!
[Information] Executed DbCommand ("2"ms) [Parameters=["@__p_3='20'"], CommandType='Text', CommandTimeout='30']"
而同样的代码在 .NET Framework 中没这个问题,看来是 AutoMapper
与 EF Core
相处不融洽。
原因已经找到,那如何解决或避开这个问题呢?这时想到了刚认识不久了解不多的新朋友 —— Mapster ,换上对象映射界的新秀 Mapster
试试。
将 ProjectTo
改为 ProjectToType
,并如下配置映射关系:
TypeAdapterConfig<BlogPost, BlogPostDto>.ForType()
.Map(dest => dest.AuthorUrl, src => "https://www.cnblogs.com/" + src.BlogSite.Application + "/");
运行后惊喜地发现 Mapster
没这个问题,多次运行 Executed DbCommand
都在 10ms
以内,千倍之差,让人眼前一亮的新秀。
[Information] Executed DbCommand ("2"ms) [Parameters=["@__p_3='20'"], CommandType='Text', CommandTimeout='30']"
在这冬去春来之际,由于遇到这个问题,也到了我们辞去 AutoMapper
迎来 Mapster
的时候。
原文地址:https://www.cnblogs.com/dudu/p/10449485.html