Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

LINQ vs. SQL in Ignite.NET: Performance

DZone's Guide to

LINQ vs. SQL in Ignite.NET: Performance

Ignite.NET offers a LINQ provider which translates C# expressions to SQL queries. LINQ has many benefits over SQL — but at what cost?

· Performance Zone
Free Resource

Download our Introduction to API Performance Testing and learn why testing your API is just as important as testing your website, and how to start today.

Before reading, a detailed explanation of Ignite.NET distributed queries can be helpful: Getting Started With Apache Ignite.NET Part 3: Cache Queries. If you are new to Ignite, please read that first.

Benchmark Results

Let’s get straight to the results!

            Method |      Median |    StdDev |
------------------ |------------ |---------- |
         QueryLinq | 175.8261 us | 9.9202 us |
          QuerySql |  62.2791 us | 5.4908 us |
 QueryLinqCompiled |  57.9274 us | 3.1307 us |

(The code is here.)

This is a comparison of equivalent queries via SQL, LINQ, and Compiled LINQ. The query is very simple (select Age from SqlPerson where (SqlPerson.Id < ?)), data set is very small (40 items, 20 returned): this exposes LINQ overhead better.

We can see right away that LINQ is a lot slower than raw SQL, but compiled LINQ is a bit faster. Note that results are in microseconds; real-world queries may take tens or even hundreds of milliseconds, so LINQ overhead will be hardly noticeable.

Anyway, how can we explain these results? Why compiled LINQ is faster than raw SQL?

How Ignite LINQ Works

ICache<int, SqlPerson> cache = ignite.GetCache<int, SqlPerson>("persons");

IQueryable<int> qry = cache.AsCacheQueryable().Select(x => x.Value.Age);

IList<int> res = qry.GetAll();

If we run the above code in Visual Studio debugger and look at the qry variable, we’ll see something like this:

ICacheQueryable Debug View

The compiler has translated .Select(x => x.Value.Age) to an Expression Tree and passed it to CacheFieldsQueryProvider, which, as we can see, turns into a regular Ignite.NET SqlFieldsQuery. Expression tree processing is not free — that’s where the overhead comes from.

We can get that SqlFieldsQuery and run it manually:

IQueryable<int> qry = cache.AsCacheQueryable().Select(x => x.Value.Age);

SqlFieldsQuery fieldsQry = ((ICacheQueryable)qry).GetFieldsQuery();

IQueryable<IList> res = cache.QueryFields(fieldsQry);

However, LINQ produces typed IQueryable<int> instead of untyped IQueryable<IList>. How is this achieved? You may think that LINQ engine iterates over IQueryCursor returned from QueryFields and populates List<int>, but it is more clever than that.

This code produces zero extra allocations and zero type casts while reading query results. That is where LINQ advantage comes from — it is aware of resulting data types and can generate specialized deserialization code, while regular SQL query reads all field values as objects, which causes excessive allocations (IList for each row, boxing of value types) and requires type casting.

Conclusion

LINQ is not only much nicer to work with than SQL but it can also be on par or faster when used properly! Just don’t forget to use CompiledQuery when on a hot path.

Find scaling and performance issues before your customers do with our Introduction to High-Capacity Load Testing guide.

Topics:
linq ,sql ,apache ignite ,c# ,caching ,performance ,benchmarking

Published at DZone with permission of Pavel Tupitsyn. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}