×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

I doubt it

usually people wrap the operation as follows:

using (context = new )
{
Get;
SaveChanges
}

sometimes there is another layer with transaction

I don't think Microsoft is stupid enough to open a new connection per operation; it must be cached.

But what you were suggesting is open the connection manually before I perform any operation, close it after the last one. I truly don't think that's necessary. However, I tried it anyway. According to the performance profile, it seems to be 1 second slower on average, I will respectfully say your suggestion doesn't make any difference.

Please let me know if I misinterpret your idea.

One option is to use compiled queries, but there is no (custom) query in our cases, mainly are SaveChanges and TryGetObjectByKey.

We still feel the headache, any other hints? thanks
Report

Replies, comments and Discussions:

  • 工作学习 / 学科技术讨论 / entity framework 和 DB2 用的时候效率比较低啊,特别是当 update 一个 entity with many children (1 to many) 的时候。做了 performance profile 发现都是 TryGetObjectByKey 和 SaveChanges 用的最多,有没有好的方法提高一下?
    • My two cents
      In your situations, object Services must continuously open and close the connection to the data source. You can consider manually opening the connection at the start of these operations and either closing or disposing of the connection when the operations are complete.
      • I doubt it
        usually people wrap the operation as follows:

        using (context = new )
        {
        Get;
        SaveChanges
        }

        sometimes there is another layer with transaction

        I don't think Microsoft is stupid enough to open a new connection per operation; it must be cached.

        But what you were suggesting is open the connection manually before I perform any operation, close it after the last one. I truly don't think that's necessary. However, I tried it anyway. According to the performance profile, it seems to be 1 second slower on average, I will respectfully say your suggestion doesn't make any difference.

        Please let me know if I misinterpret your idea.

        One option is to use compiled queries, but there is no (custom) query in our cases, mainly are SaveChanges and TryGetObjectByKey.

        We still feel the headache, any other hints? thanks
        • What data provider are you using?
          • IBM.Data.DB2.xxxx
            • The performance also definitely depends on data provider. IBM data provider of course is very good one to deal with DB2. So you don’t have change to improve performance here.
              In order to prevent connection leaking problem, any database operation should open and close in one unit operation by default. That is also smart not stupid. Please read Performance Considerations for Entity Framework Applications from following url: http://msdn.microsoft.com/en-us/library/cc853327.aspx. Hope you can get some hint there.

              Generally speaking, performance of entity framework is better than LINQ but poorer than directly SQL.

              If the performance of your operation does affect your whole operation, you might think about to use SQL rather than entity framework.