Home > .net 3.5, c#, Fluent NHibernate, LINQ, NHibernate, SQL > Benchmarks : Comparing LINQ to NHibernate Transforms/Grouping

Benchmarks : Comparing LINQ to NHibernate Transforms/Grouping

June 12, 2009

Yesterday, I wrote about setting up NHibernate to query up, group, count, and transform results and return them into a control.  Why did I go to such effort?  Well, the original LINQ query I had that refined the results didn’t perform up to par.  As some may note, premature optimization is never a good practice so I needed some stats to back up the claims.

Overnight, I wrote up a quick test to query up both ways and benchmark the results.  Here’s what I found.

The “test”:

public void TEMP_quick_compare_of_linq_to_nhibernate()

{

    var schoolId = 120;

 

    var benchmark = new Benchmark();

    using (var repository = new IncidentRepository())

    {

        benchmark.Start();

        var resultsFromLinq =

            repository.GetCountByIncidentCodeWithLinq(schoolId);

        foreach (var item in resultsFromLinq)

        {

            Console.WriteLine(item);

        }

        benchmark.Stop();

        Console.WriteLine(“Linq: {0}”.AsFormatFor(benchmark.ElapsedTime));

 

        benchmark.Start();

        var resultsFromNhibernate =

            repository.GetCountByIncidentCode(schoolId);

        foreach (var item in resultsFromNhibernate)

        {

            Console.WriteLine(item);

        }

        benchmark.Stop();

        Console.WriteLine(“NHibernate: {0}”.AsFormatFor(benchmark.ElapsedTime));

    }

}

Setting up the benchmark (and the NHibernate Init) are outside of the benchmark—they’re necessary overhead.  I’m also iterating through each of the results as part of the benchmark to ensure that everything is evaluated. Past that, pretty basic.  On the database side, I’ve disabled statement caching to not sway the results as much.

With 24 records (the test data in the system), the results were pretty clear. The average of running the benchmark 100 times resulted in…

Linq: 00:00:00.7050000
NHibernate: 00:00:00.0190000

With 24 records, NHibernate was about 37x faster. 

That’s nice, but what happens in a few weeks when there are a few thousand records?  I populated a few hundred of each incident type into the system, giving me almost 4000 records (the anticipated monthly load of the system by the customer).  How’d that change our averages?

Linq: 00:00:00.8869746
NHibernate: 00:00:00.1381518

Now we’re only 6x faster with NHibernate vs. LINQ.  The duration from 24 to 4000 records for LINQ  jumped ~.18 seconds for a 25% gain where as NHibernate jumped ~.11 seconds for a 626% gain.

So, with that, my original gut feeling and assumptions were wrong.  More and more records don’t really slow down the LINQ filtering.. at least not by much.  The performance gain is still appparent between the two methods (.88 sec vs. .13 sec); however, how much of that time is eaten up by rendering, server latency, etc and not by the actual processing?

  1. wizard
    June 15, 2009 at 4:07 am

    Hai, just want to know what is the tool that you use for benchmarking linq and nhibernate?
    So the conclusion of your article above is, nhibernate is not slow down the performance just like the issue out there? I want to use Nhibernate for my project but I afraid it will slow down the performance of the application. Please give me some advice.
    Thanks a lot.

  2. June 15, 2009 at 10:13 am

    @Wizard-

    To benchmark, I use a simple method to compare start and stop time (to find elapsed time). My current method is derived from http://is.gd/12AuF, a similar method I wrote last year to do something similar in ASP.NET trace pages.

    NHibenate, if you notice the comparisons, is actually OVERALL faster–much faster actually. However, the code required to transform the data as well as the additional transform class methods and junk doesn’t save the developer (me) any time.

    In addition, the difference between 25 records and 4000 isn’t real substantial to LINQ, but does increase NHibernate’s generation time by a higher margin (even though it’s still much less than LINQ).

    As I mentioned, I’m more concerned that my _implementation_ is flawed, not NHiberate or how the methods work. There’s got to be a more succinct way to code these groupings.😉

    • Wizard
      June 15, 2009 at 7:28 pm

      Well now I really get confused, what I hear from my friend, hibernate is save a lot of time for us (developer). What code do we need to do for transforming the data? I think hibernate have already return the data we need in object form, not in primitive object (ie. int or string).
      Currently I have a plan to use ORM in my project, the purpose of course to build a loosely coupled application and more easy to maintain. After research and googling around, I found out nhibernate suit for my requirement. But still I don’t have time to try it on my own, so I want to ask for your opinion about this. Does hibernate really can make the application we build loseely coupled and more easy to maintain?
      What I mean easy to maintain is like this, when our application need to change (ie. our table change it’s field from 5 field to 6 field), we can easily change our code not in all place, but just in 1 or 2 place (ie. data layer or business layer).
      Please share some of your experience using nhibernate, maybe you can write in a new article.
      Thanks a lot.

      • June 15, 2009 at 7:32 pm

        I’d suggest reading my original post (this post here is part #2) discussing my comparisons of grabbing a IList and using LINQ to divvy out the business logic OR pushing that back into NHibernate.

        NHibernate is AWESOME and I highly recommend it. These two posts don’t summarize NHibernate and it’s performance (and usability) overall, more of just the case I’m facing now (transforming what seems like a basic TSQL into NHibernate ICriteria).

        Original post: http://is.gd/12Xxz

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: