首页 > 代码库 > EF循环迭代导致性能的丢失,你知道?

EF循环迭代导致性能的丢失,你知道?

前言

在工作当中呢,没怎么用到过EF,所以为了遗忘这一部分知识,偶尔会去写写小的demo,偶然机会在EF循环迭代中发现居然影响性能这么严重,当我们在用时或许大概也许可能都曾这样写过,但是你注意到了吗,你怀疑过吗?这就是本节所要讨论的话题。若有错误,请批评指出。

话题

关于基础知识我们就不废话了哈,我们假设这样一个场景(不一定严谨,只是为了引出话题):当在下单中,如果有多个人下单,此时我们需要通过订单Id去得到客户Id。在这一场景中我们给出一个订单类以及订单处理类。如下:

     //订单类     public class Order    {        public int Id { get; set; }        public int OrderId { get; set; }        public int CustomerId { get; set; }        public string Filed1 { get; set; }        public string Filed2 { get; set; }        public string Filed3 { get; set; }        public string Filed4 { get; set; }        public string Filed5 { get; set; }    }
    //订单处理类    public class OrderProcess    {        public int OrderId { get; set; }        public int CustomerId { get; set; }    }

订单类是poco类存于数据库中,而订单处理类为将订单类进行DTO的类,我们将订单Id传到订单处理类中,通过订单类来获取到客户Id并赋给订单处理类中的客户Id。

为了大家可能方便测试,将其余说了很多次的映射类以及上下文都给出来。

    //订单映射类    public class OrderMap : EntityTypeConfiguration<Order>    {        public OrderMap()        {            HasKey(k => k.Id);            Property(p => p.OrderId);            Property(p => p.CustomerId);            Property(p => p.Filed1);            Property(p => p.Filed2);            Property(p => p.Filed3);            Property(p => p.Filed4);            Property(p => p.Filed5);        }    }
    //EF上下文以及预热    public class EFDbContext : DbContext    {        public EFDbContext()            : base("name=EFIteration")        {            var objectContext = ((IObjectContextAdapter)this).ObjectContext;            var mappingCollection = (StorageMappingItemCollection)objectContext.MetadataWorkspace.GetItemCollection(DataSpace.CSSpace);            mappingCollection.GenerateViews(new List<EdmSchemaError>());        }        /// <summary>        /// 通过反射一次性将表进行映射        /// </summary>        /// <param name="modelBuilder"></param>        protected override void OnModelCreating(DbModelBuilder modelBuilder)        {            var typesRegister = Assembly.GetExecutingAssembly().GetTypes()                .Where(type => !(string.IsNullOrEmpty(type.Namespace))).Where(type => type.BaseType != null && type.BaseType.IsGenericType && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));            foreach (var type in typesRegister)            {                dynamic configurationInstance = Activator.CreateInstance(type);                modelBuilder.Configurations.Add(configurationInstance);            }        }    }

在数据库中对订单表生成了20万条数据。我们在订单处理类中随机插入100条订单Id,如下:

            var orderProcessList = new List<OrderProcess>();            for (int i = 0; i < 100; i++)            {                var random = new Random();                var number = random.Next(1, 200000);                var orderProcess = new OrderProcess() { OrderId = number };                orderProcessList.Add(orderProcess);            }

为了将订单类中客户Id赋给订单处理类中客户Id,你是不是会像如下这样操作呢?

            var context = new EFDbContext();            foreach (var op in orderProcessList)            {                var order = context.Set<Order>().FirstOrDefault(o => o.OrderId == op.OrderId);                op.CustomerId = order.CustomerId;            }

此时我们来测试下耗费的时间。

技术分享结果是3.2秒,看到这里有人就说了,而且大家都看到过都知道,在查询时为了性能我们可以关闭EF的变更追踪,于是乎就有了下面的代码:

改良一

 var order = context.Set<Order>().FirstOrDefault(o => o.OrderId == op.OrderId);//替换成 var order = context.Set<Order>().AsNoTracking().FirstOrDefault(o => o.OrderId == op.OrderId);

此时看看演示结果:

技术分享

此时耗费的时间为1.7秒,当然有时会更短,反正比上述加了变更追踪情况的耗费时间要少。

到了这里你是不是就觉得已经很满足了呢?是不是觉得已经得到了很大的改善了呢?要是这样关闭变更追踪就可以解决了问题,那我这篇文章你说还有什么意义呢?好了废话不多说。本文讨论的话题就在于EF的迭代问题,难道仅仅只有上述一种方式能达到我们的需求吗,上述我们将ef迭代放在了遍历订单处理类中,我们难道就不能事先得到符合条件的订单Id,然后直接取到对应的客户Id呢?思路来了。

改良二

(1)筛选出符合订单处理类中的订单。

            var orderToProcessIds = orderProcessList.Select(o => o.OrderId).ToList();            var allOrders = context.Set<Order>().AsNoTracking().Where(o => orderToProcessIds.Contains(o.OrderId));

(2)将符合条件的订单转换成以订单Id为键的字典。

            var allOrdersDictionary = allOrders.ToDictionary(o => o.OrderId);            foreach (var op in orderProcessList)            {                var order = allOrdersDictionary[op.OrderId];                op.CustomerId = order.CustomerId;            }

这样不就解决了每次都要去迭代订单吗。接下来我们来测试比较改良一和改良二中耗费的时间。

技术分享 改良一中的耗时为3.4秒,改良二中耗时为0.3秒,通过小小的改善是不是又将性能提升了10倍呢!不必多说,你懂的!

总结

本节我们验证了在EF循环迭代中会导致性能的丢失,我们无意中的操作就导致性能的丢失,有时候转换思维很重要,从上面可以看出:能够避免的应该尽量避免在遍历数据时去进行EF的循环迭代。好了,本来打算早点睡觉的,偶然发现这样也会导致性能的丢失,于是马不停蹄导致本文的产生。

EF循环迭代导致性能的丢失,你知道?