@Dave R
I think we aren’t entirely in disagreement.
I explicitly detailed the size of my data and stated that my findings may only be due to size of the data I have.
You accuse me of FUD in general, and I disagree. But I actually agree that I am generating FUD in relation to LINQ2SQL for large databases/data warehouses. You are right! I am clearly saying that it is an inappropriate technology for large databases (Doubt). I am clearly saying that it runs slower than other more appropriate technologies on larger databases (Fear). I am saying that the cost/benefit is unknown without the developer first doing benchmarking and testing (Uncertainty). YES - I am preaching FUD for Linq2sql for large databases!
I chose those links because they were some of the first ones I googled. I could probably find more - but I don’t have the time to prove myself right when I have already done that ON MY DATA. For all in know LINQ2SQL may be faster in some situations, that’s why I STILL test alternative options in order to get the desired performance.
You said the links only used a few rows, and that’s a valid issue. So, did YOU repeat the tests on that page with extra data? Did you add in 100,000 to 100,000,000 records and then look at the results? If not then give it a go - all the code was there to do just that. You don’t have to believe the site author, you CAN do the test yourself on data that matches the size of tables you deal with.
Chances are you can’t be bothered, and I don’t blame you. I only started benchmarking and testing when I first noticed massive slowdowns when using LINQ2SQL, which is what woke me up to the issue.
I actually agree that there is a balance between the benefits of LINQ2SQL. I DO use Linq2sql for small/quick tasks, the problem is that majority of my data tasks are over large volumes of data. If something takes at least 16 ms to run… you could make it 10 times slower and I’m not going to care. BUT if something takes at least 60 seconds to run, you can put money on the fact I will be doing everything I can to make sure that’s all it takes to run.
You mentioned the “small” penalty of LINQ, and this is where the size of the data becomes important. For large data it isn’t a small penalty to use LINQ, it is a large one.
To be very specific, I have one table where the current row count is 3,505,920, and another that is 22,381,736. These tables are accessed very frequently. I simply can’t get the performance out of LINQ2SQL to justify its use.
I have several hundred concurrent users. I am about to have maybe 800 mobile vehicles that log their gps position every 30 seconds AND provide extra data and GPS positions during specific events - producing a mind blowing amount of daily data.
So for me the speed impact of LINQ matters. StackOverflow? I don’t know - that’s up to them to do their own technology comparisons and tests. For you? I don’t know.
If you take it that I am generating FUD – fair enough, but the fear, uncertainty and doubt can all be eliminated by some very simple benchmarks that data developers should be doing.
This is my last post on this page - I’ll come back to read if you want to post anything else, but I think I’ve made my case as clear as I’m able to.