Slow Cache QueryStrategy

 

Your real question seems to be why is DevForce so much slower than accessing the Dataset directly.  I would argue that you have selected the worst possible benchmark.  You have selected a benchmark that requires thousands of queries and each query can only access one orderdetail and one product id.   In a real application, you wouldn't make this query, you would make a single query asking which of 1000 orderdetail reciords contained one of 10 product ids.  That query should give the best possible result, and I don't think it makes any appreciable difference whether you use your oen algorithms or ours.

 

I'll admit that in some cases your strategy may give better results than ours, but what I'd like to know is how often this happens and what are these queries.  My bet is that in most cases, you'll do best by minimizing the number if queries rather than optimizing the performance of a single detailed query.

 

I think that the issue really comes down to the issue of how much "information density" you have in each query result.  If each query result returns a lot of information, your algorithm won't help much.  If each query reult returns minimal information, and you have to make a lot of queries, your strategy will do much better.

 

Creating a dictionary is not free.  If we included the cost of dictionary creation, your results would not look so good.  You may argue that dictionary creation only happens once, but many queries are run very infrequently during an application.

 

Finally, I leave you with tthis hought from one of pur architects:

 

"DevForce gives great performance for the vast majority of our custoners.  Only when you see unacceptable performance should you focus on trying to address your performance issue

 

Premature optimization is a common and deadly development error.  This is a slippery slope."

 

David