EF Core 相关的千倍性能之差（ AutoMapper ProjectTo VS Mapster ProjectToType）

但使书种多，会有岁稔时。这篇文章主要讲述EF Core 相关的千倍性能之差： AutoMapper ProjectTo VS Mapster ProjectToType相关的知识，希望能为你提供帮助。
在前两天遇到 .NET Core 中 EF Core 的异步与同步查询的百倍性能之差之后，这两天又遇到了 `AutoMapper ProjectTo` 与 `Mapster ProjectToType` 的百倍性能之差。问题是在昨天发现的，使用 `AutoMapper ProjectTo在前两天遇到 .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 左右，从中可以推测某个原因造成获取单条记录增加了额外的开销。
【EF Core 相关的千倍性能之差（ AutoMapper ProjectTo VS Mapster ProjectToType）】而用同样的 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.songbingjia.com/android/>"https://www.cnblogs.com/" + src.BlogSite.Application + "/");

运行后惊喜地发现 Mapster 没这个问题，多次运行 Executed DbCommand 都在 10ms 以内，千倍之差，让人眼前一亮的新秀。