tabs ↹ over ␣ ␣ ␣ spaces

Comparing speed of “Count > 0” and “Any”

29 Sep 2017 14 mins .NET, C#, LINQ

I hate seeing Count > 0 when doing code reviews. And I always recommend using Any instead. It shows the intention, hence makes the code more readable, I think.

Although I would always choose readability over performance – unless in some very specific cases, with well-defined numbers – at one point I wondered whether there’s a cost in using Any. Speed? Allocations?

Me being me, I decided to test it. Maybe LINQ is optimized (yeah, I know, I could check the sources) for arrays or lists or … Let’s test.

For different collections, namely arrays (int[]), lists (List<int>) and hashtables (HashSet<string> and Dictionary<int, string>) I measured speed as a primary metric and allocations as secondary metric. The comparison was run with colections having 0, 1, 10, 20, 40, 100, 1000, 10000, 100000 and 1000000 items. Everything using .NET Core 2.0 and RyuJIT on 64-bit. Of course I used BenchmarkDotNet.

The code in test was minimal.

collection.[Count|Length] > 0
collection.Any()
collection.Count() > 0

The Count() > 0 is there because it’s the same for arrays and rest of the collections, compared to Length (arrays) and Count (rest), which makes it easy to swap collections.

Array (int[])

Without any surprise the property beats LINQ hard. Four orders of magnitude. For non-empty collections there’s small allocation (32B) in Any in Gen 0. Across the array sizes the Any is roughly 1/3 faster than using Count.

List (List<int>)

Again, the property is winner in all categories. But compared to arrays, the LINQ is now only about two to maybe-three orders of magnitude slower. Also Any is now slower, and with small allocation, than Count, about 2,8×. The numbers are fairly consistent across list sizes.

Hashset (HashSet<string>)

For hashsets the property again wins and the times are similar to what we can see with lists (including the consistency). The LINQ is two to three times slower compared to lists (with same allocations), with Any being slower than Count, about 2,6×.

Dictionary (Dictionary<int, string>)

This time, although the property again wins, it’s not in hundredths of nanoseconds, but in tenths. LINQ is a bit faster than in hashsets, with Any being slower than Count (as with lists and hashsets), about 2,6×. The allocation raised to 56B (in Gen 0) across the sizes.

Summary

What we can deduct from these numbers? Here are my observations.

• Using a property directly is heaps faster than LINQ.
• The Count method is indeed optimized for collections with known length, so it’s not counting the elements one by one.
• Except for arrays, the Count method is faster than Any, but not much.
• Any allocates some bytes (depending on collection type). Although it’s a small allocation, it’s an allocation nonetheless.

Does it mean I’ll stop using Any? No. As I said, Any shows the intent clearly. I write readable code first, often that also means performant enough, and optimize later when needed and backed by numbers.

Jiří Činčura is .NET, C# and Firebird expert. He focuses on data and business layers, language constructs, parallelism, databases and performance. For almost two decades he contributes to open-source, i.e. FirebirdClient. He works as a senior software engineer for Microsoft. Frequent speaker and blogger at www.tabsoverspaces.com.