Skip to main content

C#: LINQ and Foreach performance comparison

I'm currently solving performance issues we have programmed within the last milestone. A lot of bugs were already fixed but very interesting issue hasn't.

I have liked and preferred LINQ queries over simple foreach command. Mentioned performance issue was based on the following query.

Entity e = entities.Where(e => e.Id.Equals(id)).FirstOrDefault();

Our list contains few items, for the worst case the only one. It's necessary to make the search because there can be obviously more items. I was surprised by results raised from simple test which is attached at the bottom of current article.

Test simply inserts 1, 50 and finally 100 unique entities to the list. Each entity holds only string identificator (UUID). Each listed algorithm try to find entity placed at the end.

I have tried these approaches:

  1. LINQ query
  2. simple foreach
  3. map having entity id as key

The result is very interesting as attached table and chart show. The map was included only for the confrontation, it obviously doesn't support any querying.

Conclusions: LINQ, foreach or dictionary?



It seems that querying above IList with using LINQ spent significant time to initialize the whole technology. LINQ query can be almost 10x worst than simple foreach for small amount of data. Note that for the described issue, the map is total winner because it has constant search response.



Reject LINQ? No!

The results are not so bad for LINQ as it can be seen. Consider that boundary 7 second is for one million of calls in the case of 50 items within list. So LINQ takes 7 microseconds for one search, foreach six. There is also almost no difference in absolute relations when there is small amount of items within list. LINQ 0.9 microsecond, foreach 0.1 micro. I believe that LINQ can be rejected only for very performance tuned solutions.

Comments

Popular posts from this blog

NHibernate performance issues #3: slow inserts (stateless session)

The whole series of NHibernate performance issues isn't about simple use-cases. If you develop small app, such as simple website, you don't need to care about performance. But if you design and develop huge application and once you have decided to use NHibernate you'll solve various sort of issue. For today the use-case is obvious: how to insert many entities into the database as fast as possible? Why I'm taking about previous stuff? The are a lot of articles how the original NHibernate's purpose isn't to support batch operations , like inserts. Once you have decided to NHibernate, you have to solve this issue. Slow insertion The basic way how to insert mapped entity into database is: SessionFactory.GetCurrentSession().Save(object); But what happen when I try to insert many entities? Lets say, I want to persist 1000 libraries each library has 100 books = 100k of books each book has 5 rentals - there are 500k of rentals  It's really slow! The inser

Performance Battle of NoSQL blob storages #1: Cassandra

Preface We spend last five years on HP Service Virtualization using MsSQL database . Non-clustered server. Our app utilizes this system for all kinds of persistence. No polyglot so far. As we tuned the performance of the response time - we started at 700ms/call and we achieved couple milliseconds per call at the end when DB involved - we had to learn a lot of stuff. Transactions, lock escalation , isolation levels , clustered and non clustered indexes, buffered reading, index structure and it's persistence, GUID ids in clustered indexes , bulk importing , omit slow joins, sparse indexes, and so on. We also rewrite part of NHibernate to support multiple tables for one entity type which allows use scaling up without lock escalation. It was good time. The end also showed us that famous Oracle has half of our favorite features once we decided to support this database. Well, as I'm thinking about all issues which we encountered during the development, unpredictive behavio

Jenkins + git revision in all build names

Jenkins by default assigns version of a build using local counter within each type of a build. An example is better. When you look at this overview, you definitely do not know which code revision was used in Compile build and which in Integration Tests . I've followed nice article regarding real CI pipeline using jenkin s. It uses Build Name Setter Plugin. Unfortunately this article uses SVN revision number. So I said I'll just use git revision as git is my source control. But it's not so easy as how it could seem for first look. My Jenkins setup comprised of first compile build step which clones git server and performs an compilation. Second build steps clones the repository from first step and executes integration tests . The problem here is that the second step does not know which git revision compile step cloned. Here is list of steps how to do that. 1. You obviously need Git Plugin , Build Name Setter Plugin and Parameterized Trigger Plugin 2. Compile