I am running some LINQ comparision tests against LLBLGen Pro 2.6 and the built in LINQ to SQL. I use the exact same query for both but LINQ to SQL returns the results twice as fast as LLBLGen Pro?

Here is the LINQ code I am using which takes 0.3291276 to run using LLBLGen Pro against a table with 150,000 records in it.

    ' LLBLGen Pro LINQ Test
    stopWatch.Start()
    Dim db As New LinqMetaData  'DataClasses1DataContext
    Dim products = _
        From product In db.Inventory _
        Where product.Item.StartsWith("8000") _
        Order By product.SalesPrice Descending _
        Select product

    ' Loop through the results
    For Each product As Object In products
        Console.WriteLine(product)
    Next
    stopWatch.Stop()
    MessageBox.Show("Time Elapsed: " & stopWatch.Elapsed.ToString)

All I do is replace the LinqMetaData with the DataClasses1DataContext to run against LINQ to SQL and the exact same code runs in 0.1692717.

It appears that native LINQ to SQL runs twice as fast compared to LLBLGen Pro. Is that true or am I doing something wrong?

When I try to step through the code it seems like it runs hundreds of lines of code as there are a ton of classes the LLBLGen Pro created. I also ran this test compiled and the results were the same.

Any ideas?

Sam

I don't work for Solutions Design but I would suggest try a more complicated query with prefetch paths and circular references to get a better "real world" comparison. Then try to do updates, adds and deletes to the children objects with each.

If you simply ran our query first and then linq 2 sql, you'll always get the second one to be faster: 1) connection is available in connection pool 2) database has read data from disk into memory 3) query is cached and results are streamed to client without much overhead.

That said, in O/R mapper land there's a simple rule: the most simple O/R mapper is the fastest when it comes to simple straight forward entity fetching. The reason is simple: there's less overhead because the simple o/r mapper is simply copying values from the datareader into some object and that's about it.

LLBLGen Pro's fetch pipeline is optimized to the point where we couldn't find a point to optimize anymore. Linq to sql has some advantages on this as they pre-generate IL to fetch the data (so that's a bit faster) and have less overhead in the entities because the O/R mapper is simple. (we do authorization calls etc. for example, check if dependency injection has to take place. It's all very quick if nothing has to be done but still takes a bit of time and if you fetch a lot of rows, it will add up)

The downside of linq to sql is that their linq provider, albeit solid, is very slow. A complex linq query can take a long time (relatively speaking) to parse, and with llblgen pro that's not the case. Also, as Arschr has pointed out, more complex scenarios will show you a totally different picture: http://weblogs.asp.net/fbouma/archive/2008/03/07/developing-linq-to-llblgen-pro-part-14.aspx

So 'it depends'. In the end, nothing beats a raw datareader. If you want optimal performance, you have to use a raw datareader as every other thing is slower and making concessions towards performance, you thus end up there, OR accept that features take time, and that the question has to be: "Ok, features take time, is the code optimal and profiled accordingly so the best performance is reached considering these features?" I can only say: Yes. If there would be another bottleneck somewhere, we'd fix it, but I don't know of any other bottleneck, simply because that would mean cutting out a feature and that would mean we'll end up on the slippery slope towards a raw datareader (which we offer you to use btw, if you don't agree with our entity fetch speed, you can use our projection system by fetching a datareader as a projection and use a custom entity projector to create a faster entity projection system if you want )

Thanks for all the detailed replies. That all makes a lot of sense. I am seeing faster results in more complex queries.

I decided to try another test on the same query above and the results were very interesting.

I ran the LINQ to SQL query twice in a row and the first time it took .1692717 and the second time was faster running at .0151684.

Then I ran the same query using LLBLGen Pro twice in a row and the first time was .3291276 but the second time was blazing fast at .0050807. That's over 3 times faster than LINQ to SQL.

So it does appear that the very first time LLBLGen is a little slower than L2S but after that it's much faster.

Sam

Are you sure the second time you checked the LLBLGen Pro query you got results back? 0.005 seconds is really fast for 150.000 rows (not that I complain, but it looks like you made an error somewhere, can't imagine it's that fast.

the 0.2ms setup time is the hit you take when the config file is parsed, connection string is read, other things are setup in static ctors, and the like, it's a one time hit. I'd expect subsequential fetches to be around 0.18-0.2, so nearing linq to sql (in the basic query you specified above).