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

在前两天遇到 .NET Core 中 EF Core 的异步与同步查询的百倍性能之差(详情之前的博文)之后,这两天又遇到了 AutoMapper ProjectToMapster ProjectToType 的千倍性能之差。

问题是在昨天发现的,使用 AutoMapper ProjectTo + 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()
    .ToListAsync();

在配置映射时使用了字符串连接:

conf.CreateMap()
    .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 中没这个问题,看来是 AutoMapperEF Core 相处不融洽。

原因已经找到,那如何解决或避开这个问题呢?这时想到了刚认识不久了解不多的新朋友 —— Mapster ,换上对象映射界的新秀 Mapster 试试。

ProjectTo 改为 ProjectToType ,并如下配置映射关系:

TypeAdapterConfig.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 的时候。

你可能感兴趣的:(EF Core 相关的千倍性能之差: AutoMapper ProjectTo VS Mapster ProjectToType)