CRM 2011 Early Binding vs Late Binding Performance

Early binding versus late binding, which is faster?


The MSDN provides the definitive answer on this.

Best Practices for Developing with Microsoft Dynamics CRM

Use Early-Bound Types

Use the Entity class when your code must work on entities and  attributes that are not known at the time the code is written. In addition, if your custom code works with thousands of entity records, use of the Entity class results in slightly better performance than  the early-bound entity types. However, this flexibility has a disadvantage because you cannot verify entity and attribute names at  compile time. If your entities are already defined at code time and slight performance degradation is acceptable, you should use the early-bound types that you can generate by using the CrmSvcUtil tool. For more information, see Use the Early Bound Entity Classes in Code.

Choose your Development Style for Managed Code for Microsoft Dynamics CRM

Entity Programming (Early Bound vs. Late Bound vs. Developer Extensions)

Early Bound … Serialization costs increase as the entities are converted to late bound types during transmission over the network.

As I was interested to know how “slight” the performance degradation was I completed some simple profiling.  I performed two separate test runs for both early and late binding methods.

  • Short: Creating 200 accounts.
  • Long: Creating 5000 accounts.

For a test environment I used a new un-modified CRM Online environment.

The code I used (snipped for blog purposes):

CrmConnection connection = new CrmConnection("Connection");
var service = new OrganizationService(connection);

//Early binding
Account a = new Account();
a.Name = "Via Context";

//Late binding
Entity e = new Entity("account");
e["name"] = "Via Service";

As promised by the MSDN in both test runs the late binding was faster, by about 8.5 seconds. I ran the tests a couple of times and received broadly similar results each time.

Perhaps the most interesting thing to note is that the early binding initially starts significantly slower. It then gains speed and reaches a speed similar to (but slower) than the late binding approach. Whilst late binding stays relatively flat for the entire process (ignoring a little variance).

This means that over very short runs (10-20 records) the late binding approach runs about 90% faster. Moving up to the 200 mark late binding is still 30% faster. Its only when 1500 mark is reached that late binding is less than 5% faster.





Full source

using Microsoft.Xrm.Client;
using Microsoft.Xrm.Client.Services;
using Microsoft.Xrm.Sdk;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication3
    class Program
        static void Main(string[] args)
            CrmConnection connection = new CrmConnection("Connection");
            var service = new OrganizationService(connection);

            Console.WriteLine("Early Bound - Short");
            CreateAccounts("Early Bound - Short", 200, 10, () =>
                Account a = new Account(); //Generated via SvcUtil
                a.Name = "Via Context";


            Console.WriteLine("Late Bound - Short");
            CreateAccounts("Late Bound - Short", 200, 10, () =>
                Entity e = new Entity("account");
                e["name"] = "Via Service";


            Console.WriteLine("Early Bound - Long");
            CreateAccounts("Early Bound - Long", 5000, 250, () =>
                Account a = new Account();
                a.Name = "Via Context";


            Console.WriteLine("Late Bound - Long");
            CreateAccounts("Late Bound - Long", 5000, 250, () =>
                Entity e = new Entity("account");
                e["name"] = "Via Service";



        static void CreateAccounts(String name, int runs, int sample, Action action)
            StreamWriter file = new StreamWriter("c:\\temp\\evl3.txt", true);

            Stopwatch stopwatch = new Stopwatch();


            for (int i = 1; i <= runs; i++)
                if (i == runs || i % sample == 0)
                    Console.WriteLine(i + "," + stopwatch.ElapsedMilliseconds);
                    file.WriteLine(i + "," + stopwatch.ElapsedMilliseconds);




23 thoughts on “CRM 2011 Early Binding vs Late Binding Performance

  1. Nice but not very representative, it’d be good to see more detailed view on what is actually happening (i.e. on premise vs. online, what kind of proxy, authentication, etc.).

    Are you making service calls in a loop, instead of submitting once? Any more info about the environmental factors?

    Can you post the rest of your code?

  2. Hey Mac,

    This isn’t the most thorough performance analysis, but I do feel it is representative of the statements on the MSDN. My aim was to get some rough and ready evidence to reflect the statements on the MSDN which I think this does.

    To connect to CRM I used CrmConnection class from Microsoft.Xrm.Client.CrmConnection (

    I used a brand new CRM Online trial and I ran the service calls from my work laptop over my home network to the internet. So uncontrolled environmental factors will definitely have occurred – I suspect that’s why on the short run there in jump in elapsed time around the 130 record mark.

    I’ll add my code to the the main post shortly.

    • Thank you for the code, I’ll run it on an on-premise setup to see how it stacks up, I’m extremely interested in this 🙂 I have a suspicion that late bound will win anyway, but I’ll also run a separate test with code optimisations (I’ll share them back of course), and a third test with parallelisation – I wonder how that’ll turn out?

      The setup could look like this: Amazon EC2 VM with ~8GB RAM; Win2008 R2 Standard x64; SQL 2008 R2 SP2; CRM 2011 Rollup 13; default tenant/organisation – out of the box configuration; .NET 4.0 x64 and .NET 4.5 x64 for optimised/alternative tests.

      Please email me if you’d like to get admin/remote access to that VM, e.g. to do your own testing, try something else, etc.

      • That’s a very kind offer, but I’m not interested in performing any further tests at the moment.

        I expect all tests will show that late is faster, it might be interesting to compare LINQ queries to QueryExpressions.

        Let me know where you are placing your results and I’ll add a link.

  3. Nice Post. However, there is a issue with the way you are creating accounts using early binding. Instead of invoking service.Create(e) to add a new account every time which causes a commit to the DB, you can add the new accounts to the AccountSet collection using serviceContext and at the end of the process you can call serviceContext.SaveChanges. This will commit all the changes (new accounts creation) in one commit which I suspect is faster than performing the same operations using late binding.

    • You are probably right, however I was only aiming to get a simple comparison to verify the statements on the MSDN. These are far from a vigorous performance analysis, I was just looking to get some indicative results.

  4. Hi James

    Good work. A few question for everybody:
    How much of the initial difference is down to once-per-appdomain initialisation? – How do the figures compare if you run the whole short test twice? What is happening during this time and can you do anything (such as precompile serialization assemblies) to reduce some of it?

    How does using ExecuteMultipleRequest compare?

  5. Pingback: CRM 2011 Early Binding vs Late Binding Performance | Marco's Blog

  6. Pingback: Develop 1 Limited Blog | Early Binding vs Late Binding Performance (Revisited)

  7. Pingback: Early Binding vs Late Binding Performance (Revisited) - Microsoft Dynamics CRM Community

  8. Good post. However majority of the code in plugins and workflow activities tests to be small, so may be sticking with Late binding may be better idea. Also typo etc. should be captured using unit tests. What do you think? Although Linq is quick to write but when having serious performance requirement, we found that late binding works better.

  9. Pingback: General Interview Questions on Dynamics CRM (Services, Field/Form security, Auditing, etc) | CRM TIPS BY PRM

  10. Pingback: Hosk’s Top CRM Articles of the week – 10th November – Hosk's Dynamic CRM Blog

  11. Pingback: Clean Coding with CRM Late Bound Entities | WOODSWORKBLOG

  12. Good article for Creating records, but performance cannot and shouldn’t be compared using one operation alone.

    In reality, a combination of creates, updates, reads and deletes will occur which will have a massive strain on the underlying database.

    For example, when using early binding and LINQ, most developers tend to do a retrieve before doing an update. Retrieving returns all fields on all records which is not recommended practice when querying data. Subsequently doing an update one of those records will send all data back to the server – potentially causing various plugins and SQL Indexes to be updated. Yes! Even if the data in the field hasn’t changed, it still gets sent back to CRM, triggering CRM to think that field has changed, which fires any plugins registered against that field, and then an update to SQL Server, which in turn causes it to perform an update on any indexes applied to that column.

    For this reason, I stay away from early binding – it’s way too easy to cause unwanted effects on the server side.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s