What are the (dis)advantages of early bound?

Question

I\'m researching the pros and cons of early and late binding in CRM. I\'ve got a good idea on the subject but there are some points I\'m unclear about.

1. Some say

Answer 1

1. Probably not. If you want to know for certain, I would suggest running some tests and profiling the results.

However these MSDN articles suggest late binding it faster.

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.

2 & 3. You don't have to take any special action with custom fields or entities. Svcutil will generate classes for both.

Use the Early Bound Entity Classes in Code

The class created by the code generation tool includes all the entity’s attributes and relationships. By using the class in your code, you can access these attributes and be type safe. A class with attributes and relationships is created for all entities in your organization. There is no difference between the generated types for system and custom entities.

As a side note, I wouldn't get too hung up on it, they are both acceptable implementation approaches and in the majority of situations I doubt the performance impact will be significant enough to worry about. Personally I prefer late binding, but that's mostly because I don't like having to generate the classes.

---

Edit.

I performed some quick profiling on this by creating accounts in CRM, a set of 200 & 5000. It confirms the information provided by Microsoft, in both runs late binding was about 8.5 seconds quicker. Over very short runs the late binding is significantly faster - 90%. However early binding quickly picks up speed and by the time 5000 records are created late binding is only 2% faster.

Full details blogged here.

Answer 2

1. Some say that early biding is the fastest, other that late is. Is there any significant difference?

   a. Since Early bound is just a wrapper over the late bound entity class, and contains all the functionality there of, it can't have a faster runtime than late bound. But, this difference is extremely small and I differ to Eric Lippert in the What's Fastest type of questions. The one difference in speed that isn't negligible, is the speed of development though. Early bound is much faster for development, and much less error prone IMHO.

2. How does one handle early binding for custom entities?

   a. The CrmSrvcUtil generates the early bound classes for custom entities, exactly like the default ones (I created this tool to make generating the classes even easier. Update: It has since moved over to GitHub Update 2 It is now in the XrmToolBox Plugin Store, search for "Early Bound Generator" ). Each time a change is made to a CRM entity, the entity type definitions will need to be updated (only if you want to use a new property or entity, or you've removed a property or entity that you currently use. You can use early bound entity classes that are out of date, as long as you don't set the values of any properties that don't actually exist, which is the same exact requirements of late bound)

3. How does one handle early binding for default entities with custom fields?

   a. See the answer to question 2.

One of the little gottcha's when working with early bound entities, is the need to enable early bound proxy types in your IOrganizationService. This is easy for the OrganizationServiceProxy, but may take a few more steps for plugins and especially custom workflow activities.

Edit 1 - My Tests

Below is my code, testing against a pretty inactive local dev environment. Feel free to test for youself

using (var service = TestBase.GetOrganizationServiceProxy())
{
    var earlyWatch = new Stopwatch();
    var lateWatch = new Stopwatch();

    for (int i = 0; i < 100; i++)
    {
        earlyWatch.Start();
        var e = new Contact() { FirstName = "Early", LastName = "BoundTest"
        e.Id = service.Create(e);
        earlyWatch.Stop();

        lateWatch.Start();
        var l = new Entity();
        l.LogicalName = "contact";
        l["firstname"] = "Late";
        l["lastname"] = "BoundTest";
        l.Id = service.Create(l);
        lateWatch.Stop();

        service.Delete(e);
        service.Delete(l);
    }

    var earlyTime = earlyWatch.ElapsedMilliseconds;
    var lateTime = lateWatch.ElapsedMilliseconds;
    var percent = earlyWatch.ElapsedTicks / (double)lateWatch.ElapsedTicks;

}

My two test results (please note that running two test are not statistically significant to draw any sort of statistical conclusion, but I think they lend weight to it not really being that big of a performance decrease to justify some of the development gains) where ran against a local dev environment with very little other activity to disrupt the tests.

Number Creates  |   Early (MS)  |   Late (MS)   |   % diff (from ticks)
10              |   1242        |   1106        |   12.3%
100             |   8035        |   7960        |   .1% 

Now lets plug in the numbers and see the difference. 12% seems like a lot, but 12% of what? The actual difference was .136 seconds. Let's say you create 10 Contacts every minute... .136 x 60 min / hour x 24 hours / day = 195.84 s/day or about 3 seconds a day. Lets say you spend 3 developer hours attempting to figure out which is faster. In order for the program to be able to save that much time, it would take 60 days of 24/7 10 contacts / minute processing in order for the faster code to "pay back" it's 3 hours of decision making.

So the rule is, always pick the method that is more readable/maintainable than what is faster first. And if the performance isn't fast enough, then look at other possibilities. But 98 times out of 100, it really isn't going to affect performance in a way that is detectable by an end user.

Premature optimization is the root of all evil -- DonaldKnuth