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. 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