I think to get a better Benchmark on these, you should check the time in sql profiler not in google chrome, because in the browser it may be a lot of things affect the speed on the page load.
views:
321answers:
5Your speed test is a web page that, to my eyes, looks like your testing how long it takes to load. SubSonic isn't that slow and testing load time in a web page is rather ridiculous.
If you want to truly benchmark something you need to use a Console and run read loops that work against indexed data. What you've done is create a web page and say "let's see what happens on load".
This is flawed for a number of reasons. First - all of the code written needs to be compiled from IL do ML. Because SubSonic generates your code for you, and because I know you have a lot of tables here (300+ if I remember right), you can imagine there's some work going on under the covers on your first load.
To be perfectly honest here - your inexperience is undoing a lot of work I've put in for free, by posting things like "it's slow and not ready". I don't care if people use SubSonic - I do care when people do dumb things (like benchmark web tests) and blame me for it.
Based on your example you can improve the performance by using the following code:
StringBuilder Test = new StringBuilder();
int[] MiaSeira = { 5, 6, 10, 100, 7 };
for (int i = 0; i < 100; i++)
{
foreach (int EnaID in MiaSeira)
{
var Products = (from product in Product.
where MiaSeira.Contains(product.ProductID)
select product).ToList();
if (Products == null || Products.Count == 0)
continue;
foreach (Product product in Products)
{
Test.Append("<br />");
Test.Append(product.ProductName);
}
}
}
txtDebug.Text = Test.ToString();
I don't have firsthand experience with subsonic, but if it is doing a bunch of code generation, you might want to post separate results for the first request (cold), and an average of subsequent requests (warm). You should also use a Stopwatch to time just the data extraction part, so you don't conflate other timings into your data.
Aristos, here's the thing I'm having an issue with. You posted a question to our groups and we had a nice, 23-long email exchange. You insisted that SubSonic 3 has problems and you asked me why I haven't fixed this "slow, broken tool".
I tried to explain to you that, with 233 tables, SubSonic has to read the schema of EACH ONE on load up. This isn't typical usage for SubSonic 3, but we do it this way so it's actually FASTER than SubSonic 2 on subsequent loadups.
You're ingoring this. I'm answering you. RBarry left a comment above that I was beind "denigrating". I'm quite frustrated. You seem to think that I haven't benchmarked this thing and I have, MANY MANY times. I can't turn out an ORM with problems like the one you suggested, and I didn't.
You have to understand that if it took SubSonic 10 seconds to run a query, then it wouldn't be used.
So - your answer: 233 tables, scripted out as classes, need to load to Provider memory on first run.
That's too many. SubSonic isn't your tool.