Compiled LINQ query cache?

[Kendall Bennett]

Is there any support (or planned support) for automatically caching the generated queries inside OpenAccess? This is a new feature recently added to Entity Framework June 2011 CTP, which can speed up performance for queries used regularly as it will avoid the need to recompile to SQL for every LINQ query again.

I checked the documentation and I did not see anything that indicated that this is supported in OpenAccess?

[Thomas]

Hello Kendall Bennett,

OpenAccess always caches the compiled LINQ query statements for later use if the same LINQ query (with different parameters though) is executed again; we do that internally, and the application does not need to be changed / made aware of the caching.

Greetings,
Thomas
the Telerik team

[Kendall Bennett]

That is great news. Is there any support for manually compiling a query for something that is used regularly?

[Thomas]

Hi Kendall Bennett,

no, there is no manual Compile() call, it would be a no-op. All LINQ queries get compiled+cached automatically. 

Kind regards,
Thomas
the Telerik team

[Kendall Bennett]

I can see this is enabled in the back end settings for the model, but the documentation is very scarce on this matter. The default setting for this in the back end is 0, which I assume means it is turned off by default?

The problem is I have no idea what are considered 'reasonable' values to put in here? The values I assume indicates how many queries will be cached in the query cache, but what is a reasonable setting for this value? 10? 100? 1000? Does anyone have any good suggestions for a reasonable number to put in here that will give good performance but not eat up tons of memory?

[Thomas]

Hi Kendall Bennett,

the compiled (LINQ/OQL=>SQL) query cache cannot be configured or turned off. What can be configured is the compiled query _results_ cache as a part of the second level cache. The 'reasonable' number that you can use to limit this cache really depends on the chosen model, as well as the amount of data and the available memory.

Regards,
Thomas
the Telerik team

[Kendall Bennett]

Are you sure that is correct? There value I am talking about is the value listed on the 'Runtime Configuration' page of the model settings in the designer, as shown in this picture:

http://www.telerik.com/help/openaccess-orm/images/1DevEnvironment-Wizards-Model-Designer-ModelSettings-Backend-010.png

It is documented on this page:

http://www.telerik.com/help/openaccess-orm/developemnt-environment-wizards-dialogs-model-tools-designer-model-settings-backend-settings.html

and the documentation for the 'Compiled Query Cache' option says the following;

Compiled Query Cache - specifies whether to cache compiled queries.

The settings you are talking about are in the 2nd Level Cache settings dialog box, which controls where query results are cached, and how many of them are cached.

So I am pretty sure I am right in that the setting I am talking about controls how the compiled query cache is configured, and by default is set to a value of 0. I have assumed 0 means the cache is turned off, and that setting it to a non-zero value will enable it and allocate that many slots for the compiled query cache. All I really need to know now is what is considered a good value for this?

[Thomas]

Hi Kendall Bennett,

 I'm really sorry, I've given you a wrong answer (I never play with this setting). The default value is 0, which is internally translated to the default size of 1000. Negative numbers will lead to a setting of 1000 as well, so the smallest value that is settable by the user is 1. 
Again, I never change that value, it just works. The only reason to increase the value would be that you have more than 1000 different queries for which you need to store the compiled query information. This would be visible only by looking at the execution log, and we should add a metric so that the removal of compiled queries would be more visible. I will file an entry for that.

Greetings,
Thomas
the Telerik team

[Kendall Bennett]

Ok, thank kind of makes sense with my findings as I found no performance improvement changing this value from 0. In fact when I set the value to 1000 (so I assume 2000 total entries in the cache), my code ran slightly slower.

It would be nice if this was better documented :)

[Zoran]

Hi Kendall Bennett,

 Thanks for the note. We will ad this information to the documentation with the highest priority.

Best wishes,
Zoran
the Telerik team