What about performance ? Plan for "compiled queries" ?

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 ?

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 !

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.

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 !

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.

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.