Q:

Diferença performática de Any() e Count()

Quando preciso verificar se uma collection tem ou não elementos qual dos dois métodos será mais rápido, .Count() =! 0 ou .Any()?
Já ouvi falar que o .Count() pode ser mais rápido em alguns casos. Mas verificando o código fonte, o método Any() me pareceu melhor de ser usado.
Existe também a possibilidade de ter uma condição dentro do método, nesse caso pode mudar qual dos dois é mais rápido?
E quando é usado em um DbSet, a query gerada pelo .Any() é diferente da .Count() imagino eu. Mas a em questão de performance o Any() ainda continua na frente?

A:

Depende do tipo da enumeração. 
Se for baseada em ICollection<T>, .Count (propriedade, não método) é mais rápido porque o valor já é previamente calculado dentro da estrutura (otimizado). .Any() requer usar a sequência GetEnumerator() / MoveNext() / Dispose(). 
Já em quaisquer outras enumerações, .Count() (agora método) itera todos os elementos. Any() tem o fluxo interrompido ao localizar a primeira sequência, portanto, é mais rápido que .Count() 
Em resumo, Any() se comporta melhor na maioria dos casos. 

A:

Você tem razão. Pela forma que estes métodos trabalham, analisando item por item de uma coleção, há mais vantagens em usar o Any() quando você pode fazer isto.
Com o Count() você está dizendo que deseja saber quantos itens existem dentro da coleção (ou um subconjunto dela que já foi decidido por outros métodos do LINQ). A única forma de saber isto é percorrer todos os itens.
As pessoas costumam usar esta forma porque estão acostumadas com coleções puras onde você pode pedir o Count (a propriedade e não método) e tem a resposta praticamente sem custo, afinal na coleção pura, sem ter passado por uma expressão LINQ, a quantidade de itens é algo controlado pela classe e está lá disponível sempre de forma confiável e rápida.
No LINQ não tem essa facilidade, tem que percorrer tudo e contar, pelo menos em subconjuntos. Claro que pode haver otimizações que podem pegar a contagem armazenada na coleção mas não na implementação padrão (LINQ-to-Objects faz isto). E pode ser que você queira a contagem mesmo. Neste caso use-o.
Mas muitas vezes as pessoas só querem saber se existe um item pelo menos. A maneira como todos acostumaram é verificar se a contagem é maior que zero. Bem intuitivo, funciona e em coleções puras é rápido.
Mas convenhamos, se quer saber só se existe um item, não quer saber quantos tem, basta achar o primeiro item e você tem a sua resposta. Não precisa olhar para os outros itens. A resposta já será verdadeira e nada que aconteça nos outros itens poderá mudar isto.
No pior caso do Any(), que é não encontrar nada, a performance será a mesma do Count(). Em todas as outras será melhor, em muitos, absurdamente melhor.
O fato de ter uma condição que é um substituto do Where() não afeta em nada diretamente. Indiretamente pode ajudar o Any() porque fica mais fácil ele ter uma condição para encerrar a busca primeiro. No caso da otimização que falei acima, também não é possível quando há uma condição como parâmetro, assim como já não seria se usasse uma condição anterior, com um Where(), por exemplo.
Eu não consegui achar um fonte confiável e não conheço bem o Entity Framewrok para cravar uma resposta, mas pela natureza de como ele funciona, eu acredito que o mesmo continua valendo na maioria dos casos. A consulta LINQ será transformada em uma consulta SQL que terá que percorrer as linhas para contar ou achar um existente. Porém um banco de dados específico pode saber como pegar a contagem das linhas de forma otimizada em algumas situações. Aí o Count() pode eventualmente ser mais rápido. Mas note que depende do banco usado, do fornecedor LINQ dele e da situação específica. Não conte muito com isto, considere sorte quando acontecer.
Se precisar da performance mesmo, perceber que ela é fundamental e consegue ter ganhos, vai ter que fazer um código para gerenciar a escolha. Por padrão vá sempre de Any() quando só quer saber se existe.

