|
8/12/2009 12:19:35 AM
|
pkellner
Posts 2
|
Hi,
Thanks for the help today on the forums regarding views into other catalog's. I was wondering if you've done much work on linq compiles. I've spent a huge amount of time worrying and compiling linq because of the drastic performance hit it has on my web servers. Any work in that area would be much appreciated. Seems like Microsoft does not seem to think it's much of an issue.
|
|
8/12/2009 8:27:52 AM
|
Kristofer
Posts 240
|
Hi Peter,
The L2S profiler doesn't really have anything in that area (L2S tree->SQL translation impact) yet - it is (so far) more focused on performance db-side, and where in the code of a L2S app a SQL query comes from. However, it would be interesting to include some metrics on the L2S-side query generation too - I will certainly look into that... 
That said, I have done some experimenting with trying to break up the L2S expression tree parsing to cache any parts that can be cached. Internally, L2S does this recursive "tree walk" a number of times, each one having a specific task. The best way to optimize that would be to try to do more than one task in each 'tree walk', but that would require some major surgery on the internals of Linq-to-SQL. I.e. only something that could be done by Microsoft as long as the source code (and the right to recompile it) is unavailable to us mere mortals... Second best would be to attempt to cache the results of the intermediate steps. This is perfectly possible to do with reflection, but I haven't yet been able to gain any performance on doing so. Determining what to cache, and what to retrieve from the cache has - so far in my experiments - had a negative total impact on performance since that portion also need to visit every node in the expression tree to determine if a query is 'the same' as the original one... I might look into it again to try to come up with a better 'optimized tree' cache or some other mechanism that can reduce the number of times L2S has to translate a query from expression tree to SQL...
Best regards,
Kristofer
Ps. re. the views into separate catalogs - you're welcome.
edited by Kristofer on 8/12/2009
|
|
8/12/2009 9:52:11 AM
|
pkellner
Posts 2
|
I've had extensive conversations with Microsoft about this. I did some simple testing and posted the source and results on my blog (http://peterkellner.net/2009/05/06/linq-to-sql-slow-performance-compilequery-critical/) and am just amazed Microsoft doesn't do the kind of thing you are talking about for caching parts of the tree. They also say nothing changes for this in entity framework. I'm doing an enerprise app with all LINQ2SQL and have built a management layer that uses linq as it's base. I've got a pretty sophisticated code generator that cranks out base classes (actually partial classes) and uses heuristics to figure out what combination of input parameters to generate compiled linq results for. Very very ugly, but it does work for 90% of our data access.
I love LINQ and LINQ2SQL for coding, I just wish I didn't know the performance impact.
Thanks for your thoughts.
Kristofer wrote:
Hi Peter, The L2S profiler doesn't really have anything in that area (L2S tree->SQL translation impact) yet - it is (so far) more focused on performance db-side, and where in the code of a L2S app a SQL query comes from. However, it would be interesting to include some metrics on the L2S-side query generation too - I will certainly look into that... |
|
pages:
1 |
|---|