Caching Linq Query Question

I am creating a forum package for a cms and looking at caching some of the queries to help with performance, but I'm not sure if caching the below will help/do what it should on the below (BTW: Cachehelper is a simple helper class that just adds and removes from cache)

          // Set cache variables
        IEnumerable<ForumTopic> maintopics;

        if (!CacheHelper.Get(topicCacheKey, out maintopics))
        {
            // Now get topics
            maintopics = from t in u.ForumTopics
                          where t.ParentNodeId == CurrentNode.Id
                          orderby t.ForumTopicLastPost descending
                          select t;
            // Add to cache
            CacheHelper.Add(maintopics, topicCacheKey);
        }
        //End Cache

        // Pass to my pager helper
        var pagedResults = new PaginatedList<ForumTopic>(maintopics, p ?? 0, Convert.ToInt32(Settings.ForumTopicsPerPage));

        // Now bind
        rptTopicList.DataSource = pagedResults;
        rptTopicList.DataBind();

Doesn't linq only execute when its enumerated? So the above won't work will it? as its only enumerated when I pass it to the paging helper which .Tak开发者_StackOverflow中文版e()'s a certain amount of records based on a querystring value 'p'

You need to enumerate your results, for example by calling the ToList() method.

maintopics = from t in u.ForumTopics
             where t.ParentNodeId == CurrentNode.Id
             orderby t.ForumTopicLastPost descending
             select t;
// Add to cache
CacheHelper.Add(maintopics.ToList(), topicCacheKey);

My experience with Linq-to-Sql is that it's not super performant when you start getting into complex objects and/or joins.

The first step is to set up LoadOptions on the datacontext. This will force joins so that a complete record is recalled. This was a problem in a ticket tracking system I wrote. I was displaying a list of 10 tickets and saw about 70 queries come across the wire. I had ticket->substatus->status. Due to L2S's lazy initialization, that caused each foreign key for each object that I referenced in the grid to fire off a new query. Here's a blog post (not mine) about this subject (MSDN was weak): http://oakleafblog.blogspot.com/2007/08/linq-to-sql-query-execution-with.html

The next option is to create precompiled Linq queries. I had to do this with large joins. Here's another blog post on the subject: http://aspguy.wordpress.com/2008/08/15/speed-up-linq-to-sql-with-compiled-linq-queries/

The next option is to convert things over to using stored procedures. This makes programming and deployment harder for sure, but for complex queries where you only need a subset of data, they will be orders of magnitude faster.

The reason I bring this up is because the way you're talking about caching things (why not use the built in Cache in ASP.NET?) is going to cause you lots of headaches in the long term. I'd recommend building your system and then running SQL traces to see where your database performance problems are, then build optimizations around that. You might find that your real issues aren't in the "top 10 topics" but in other, much simpler to fix areas.

Yes, you need to enumerate your results. Linq will not evaluate your query until you enumerate the results.

If you want a general caching strategy for Linq, here is a great tutorial:

http://petemontgomery.wordpress.com/2008/08/07/caching-the-results-of-linq-queries/

The end goal is the ability to automatically generate unique cache keys for any Linq query.