You're right. By the way these methods work, analyzing item by item of a collection, there are more advantages to using Any() when you can do this.
With Count() you're saying you want to know how many items are in the collection (or a subset of it that has already been decided by other LINQ methods). The only way to know this is to go through all the items.
People usually use this form because they are accustomed to pure collections where you can ask for Count (property and not method) and have the answer practically without cost, after all in pure collection, without having passed a LINQ expression , the amount of items is something controlled by the class and is always available there reliably and quickly.
In LINQ you do not have this facility, you have to go through everything and count, at least in subsets. Of course there may be optimizations that can take the count stored in the collection but not in the default implementation (LINQ-to-Objects does this). And it might be that you want the same score. In this case use it.
But often people just want to know if there is an item at least. The way everyone got used to is to check if the count is greater than zero. Well intuitive. It works and in pure collections is fast.
But let's face it, if you just want to know if there is an item, you do not want to know how many you have, just find the first item and you have your answer. No need to look at the other items. The answer will already be true and nothing that happens in the other items could change this.
In the worst case of Any() , which is to find nothing, the performance will be the same as Count() . In all others it will be better, in many, absurdly better.
Having a condition that is a substitute for Where() does not affect anything directly. Indirectly it can help Any() because it is easier for it to have a condition to terminate the search first. In the case of the optimization I mentioned above, it is also not possible when there is a condition as a parameter, just as it would not be if you used an earlier condition with a Where() , for example.
I could not find a reliable source and I do not know Framewrok Entity well to get a response but by the nature of how it works, I believe that the same is still true in most cases. The LINQ query will be transformed into an SQL query that will have to traverse the lines to count or find an existing query. However, a specific database can know how to optimally take the count of the rows in some situations. Then% w / w% may be faster. But note that it depends on the bank used and the specific situations. Do not count on this much, just consider it lucky when it happens.
If you need the performance yourself, realize that it's critical and you can make a profit, you'll have to make a code to manage the choice. By default, always go from Count() when you just want to know if it exists.
