在前两天遇到 .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 的时候。