LINQtoCRM Performance

Apr 7, 2009 at 12:34 AM

I am currently evaluating the use of LINQtoCRM for integrating a web application with Dynamics CRM. I am very encouraged by the flexibility offered by the framework, however I am concerned about performance. What are some common performance issues I might run into when using LINQtoCRM, and how could I typically resolve these issues.

  • When is it best to use a QueryExpression vs the QueryProvider? I am assuming this follows the same rules for when to use Fetch vs RetrieveMultiple when retrieving large sets of data - but how much of an impact will this be (undersand that this depends on the size of data, but let's say - for a select all on 200 records).
  • What is the best way to instantiate the Service and QueryProvider in the context of a web application (i.e. how can I maximize reuse of the objects, and how thread safe is this stuff)?
  • What is the typical overhead (in ms) when using a sufficiently powerful environment and the right design patterns? (Understand this is a "it depends" kind of answer...)
  • Will using FetchXml based queries insulate me from change in the Wsdl if columns are added to entities?
  • Others stuff I might be missing...
Thanks for any help and advice you can give on this :)

Apr 7, 2009 at 7:11 AM
Those are all excellent questions. I'll answer in brief here, but I also expect to do a blog post on performance shortly.

I generally believe queryexpression, linqtocrm and fetchxml to be roughly comparable in performance. At the end of the day, xml serialization and deserialization will be done at both ends. The one case where linqtocrm may be at a disadvantage is if you do very many queries -- in a loop for example. This is because of the overhead of translating from queryexpressions to fetchxml. I would guess, however, that the overhead pr. query is not even a millisecond.

Reusing webservice and queryprovider objects should be ok but the queryprovider is not threadsafe. I don't know about the service actually.

Regarding wsdl changes, I think you should be ok using any approach. LinqtoCRM used to have a bug where it would die if it was returned columns it didn't know about, but that has been mended.

I'll try and get a blog post up shortly :-)