This project has moved and is read-only. For the latest updates, please go here.

What about performance ? Plan for "compiled queries" ?

Feb 20, 2012 at 10:57 AM
Edited Feb 20, 2012 at 10:58 AM

Hello CamlEx Team,

First, I need to say I LOVE this tool ! :) What a great idea to leave CAML heavy syntax away and give developpers more time on essential tasks ! :) It's like when Linq2Sql or Entity Frwk was coming, I was happy to be able to just forget SQL syntax ! :)

BUT, I've done some performance check, comparing CamlEx runtime query generation against string.Format() query composition and you probably guess that string formating is 10 , maybe 100 times faster ! :( (I've done simple testing with basic query likes the ones you show on te camlex home page. I can gives you the code I use to make my tests. Sometimes the query generation make same time than the query execution time on my sharepoint)

Do you have some plan to integrate something like compiled query to be able to not compute the integral expression tree each time I want the "same" caml query but with different parameter ?

i.e. :  with this sample from yours : 

// list of tokens
var tokens = new List<string> { "hello", "greeting", "hi" };
var expressions = new List<Expression<Func<SPListItem, bool>>>();

// create lambda expression for each token in list
foreach (string t in tokens)
    string token = t;
   expressions.Add(x => ((string)x["Title"]).Contains(token));

// prepare query
var caml = Camlex.Query().WhereAny(expressions).ToString();


Each time I need to execute this request but with differents tokens, The "generation" time is the same.But maybe It will be possible to generate the request with some {xx} token, replaceable next time with a simple string.format for other tokens.Then I can put this "compiled" query into static variale to reuse next time where I need the same query with same number of input parameters....
Not sure to be clear :) Not sure to have the good idea for better performance :) but I will happy if you have plan for that or maybe if I can help for that !

Feb 20, 2012 at 6:02 PM


Thanks for your feedback!

To tell the truth, I don't see the real value in any optimization for query string generation.

The execution time of generated query string is bigger in order of magnitude than the time for query string generation.

Donald Knuth said "premature optimization is the root of all evil"

Program optimization article on Wikipedia

Feb 21, 2012 at 7:27 AM

hello paslatek,

yes creation of queries via Camlex takes more time comparing with string.Format() - this is predictable. Your idea is interesting. Other libraries have similar tools, e.g. Linq 2 sql has CompiledQuery. In our case "compiled" means - transformed to string, while parameters can be added with late binding e.g. by using simple string.Replace(). But I agree with Vladimir, that in most cases in real Sharepoint applications query creation is not bottleneck. If I have really performance-critical requirements I won't store data in Sharepoint at all - will use custom database for instance.

But anyway, I will add this idea to the further development list. It is not trivial and we like non-trivial tasks. When we will implement more prioritized tasks (e.g. support of new Sharepoint 2010 CAML expressions), we will return to it.

Feb 21, 2012 at 9:01 AM
Edited Feb 21, 2012 at 9:01 AM

Hello vtimashkov & sadomovalex !

Thanks for your replies.

You probably right about that query creation is not the bottleneck. I've did my test with a very small set of data into my SharePoint plateforme, so the time to get items is near the time to create the query. I need to do my test with a bigger set of data.

But I think this depends a lot of the data size and also the SharePoint platform performance.  In some cas with intensive requesting (lot of people requesting the same type of dataset) the query creation can become a part of the bottleneck. But in this cas maybe the best scenario is to cache the resulting data instead caching the query :) ... so I must admit that maybe I search a thing that do not exist !


Feb 21, 2012 at 9:59 AM

yes exactly - you may cache whole result set (if it is rely on some parameters - add these parameters to the cache key. Doing by this you will have different caches for different queries). But as I said I think that this is interesting idea and when I will have time I will probably think about proper way to implement it.

Feb 24, 2012 at 10:24 PM

Hi vtimashkov & sadomovalex,

Firstly, great and excellent tool ... much better than creating CAML queries by hand.

I wanted to join this post because my team and I are frequently seeing that the compilation of the camlex query to a string is in many instances taking longer than actually running the query.

The speed is is generally not an issue, however, in an SharePoint application where you need to make many individual queries to populate data for one screen, this can be a problem and it can become quite slow. 

We have also started to take the approach of the initial post. We caching the caml and use tokens and string.format to speed up future requests. The idea of a some sort of compiled query or cached query would be great.