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