Any possible Value in running NGEN on assemblies?

[to11mtm]

At my workplace we are using dotConnect for Oracle alongside Entity Framework. I've done some reading on running NGEN on the Entity Framework Assemblies to speed up application startup.

Does anyone at Devart, or anyone on the forums know if it would be worth doing the same to the DotConnect assemblies? We are not installing DotConnect directly on the deployment machines, which probably makes at least a bit of a difference since when it is installed on the development boxes they are GACed (Which if I recall means they eventually get NGENed in the background.)

[Shalex]

There should be no problems with applying NGEN on the Devart.* assemblies.

Please consider the following information to improve performance of your application.

--------
Using EF
--------
Key points:
1. The Batch Updates feature increases the performance of CUD (insert/update/delete) operations made via EF: http://blogs.devart.com/dotconnect/new- ... html#Batch.
2. You can employ Oracle optimizer hints support in Entity Framework: http://blogs.devart.com/dotconnect/usin ... ework.html
3. We recommend using TransactionScope only for saving data (not for multiple read/save-s):
a) use

Code: Select all

    using (var firstConext = new FirstContext())
    {
        using (var secondConext = new SecondContext())
        {
            // ... multiple reading 1
            // ... multiple reading 2
            using (var transactionscope = new TransactionScope())
            {
                // ... saving 1
                // ... saving 2
                transactionscope.Commit();
            }
        }
    }

instead of

Code: Select all

    using (var transactionscope = new TransactionScope())
    {
        using (var firstConext = new FirstContext())
        {
            // ... multiple reading 1
            // ... saving 1
        }
        using (var secondConext = new SecondContext())
        {
            // ... multiple reading 2
            // ... saving 2
        }
        transactionscope.Commit();
    }

b) Also take into account the peculiarities of Entity Framework. For example, if you are using multiple read/save-s before applying ts.Commit(), all used connections are accumulated (they will be released only after ts.Commit()). It makes sense to open connection manually so that EF would not open/"close" them for each database interoperation - in this case EF context would use only this single connection.
Use

Code: Select all

    using (var transactionscope = new TransactionScope())
    {
        using (var firstConext = new FirstContext())
        {
            firstConext.Connection.Open();
            // ... multiple reading 1
            // ... saving 1
        }
        using (var secondConext = new SecondContext())
        {
            secondConext.Connection.Open();
            // ... multiple reading 2
            // ... saving 2
        }
        transactionscope.Commit();
    }

instead of

Code: Select all

    using (var transactionscope = new TransactionScope())
    {
        using (var firstConext = new FirstContext())
        {
            // ... multiple reading 1
            // ... saving 1
        }
        using (var secondConext = new SecondContext())
        {
            // ... multiple reading 2
            // ... saving 2
        }
        transactionscope.Commit();
    }

This is a sample for ObjectContext. In case of DbContext, it has to be cast to IObjectContextAdapter:

Code: Select all

((IObjectContextAdapter)сontext).ObjectContext.Connection.Open();

-------------------
Using plain ADO.NET
-------------------
Key points:
1. dotConnect for Oracle provides two ways of fast data insertion:
a) using the OracleLoader class -> http://www.devart.com/dotconnect/oracle ... oader.html
b) using array binding -> http://www.devart.com/dotconnect/oracle ... yBind.html
2. The fastest way of reading data is usage of OracleDataReader: http://www.devart.com/dotconnect/oracle ... eader.html

Entity Framework is slower than a plain ADO.NET because of overhead expenses: https://msdn.microsoft.com/en-us/library/cc853327.aspx.

[to11mtm]

1. The Batch Updates feature increases the performance of CUD (insert/update/delete) operations made via EF: http://blogs.devart.com/dotconnect/new- ... html#Batch.

Thanks for the info. I had a question about Batch updates however, and I'll admit I haven't had time to look into this myself yet.

Our PKs are Numbers generated by sequence so the columns in question are set to Identity.

So, going by the documentation, I get that Inserts of those entities will NOT be batched as we have 'Returning' statements. But will updates of those entities be batched so long as no properties are set to 'computed'? Also, if I'm both inserting and updating, will the updates be batched and the inserts done 'singularly' on SaveChanges()?

Thankfully, most of our application performance is already showing either an improvement or no change moving to EF (It helps that our old DAL has a lot of cruft and was working off the deprecated Microsoft OracleClient.) it's primarily the initial load/warmup that is slowing us down. Even the first time a 'new' query is generated/executed isn't much (if at all) slower than our older ADO+Cursor implementation. It's just the absolute first hit to the database.

[Shalex]

So, going by the documentation, I get that Inserts of those entities will NOT be batched as we have 'Returning' statements. But will updates of those entities be batched so long as no properties are set to 'computed'?

Yes, they will.

Also, if I'm both inserting and updating, will the updates be batched and the inserts done 'singularly' on SaveChanges()?

Yes, they will.

We recommend you to run the dbMonitor tool (documentation, download link) to enable tracing of the generated SQL.