LINQ: No Any vs All Don't

A menudo quiero verificar si un valor proporcionado coincide con uno en una lista (por ejemplo, al validar):

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

Recientemente, noté que ReSharper me pedía que simplificara estas consultas para:

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

Obviamente, esto es lógicamente idéntico, tal vez un poco más legible (si has hecho muchas matemáticas), mi pregunta es: ¿esto resulta en un impacto en el rendimiento?

Parece que debería (es decir, .Any()suena como un cortocircuito, mientras que .All()parece que no), pero no tengo nada que corrobore esto. ¿Alguien tiene un conocimiento más profundo sobre si las consultas resolverán lo mismo o si ReSharper me está desviando?

Implementación de Allacuerdo con ILSpy (como en realidad fui y miré, en lugar del "bueno, ese método funciona un poco como ..." podría hacerlo si estuviéramos discutiendo la teoría en lugar del impacto).

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (!predicate(current))
        {
            return false;
        }
    }
    return true;
}

Implementación de Anyacuerdo a ILSpy:

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (predicate(current))
        {
            return true;
        }
    }
    return false;
}

Por supuesto, podría haber alguna diferencia sutil en la IL producida. Pero no, no, no lo hay. La IL es más o menos la misma, pero para la inversión obvia de devolver verdadero en la coincidencia de predicados versus devolver falso en la falta de coincidencia de predicados.

Esto es linq para objetos solo, por supuesto. Es posible que algún otro proveedor de linq trate a uno mucho mejor que el otro, pero si ese fuera el caso, es bastante aleatorio cuál obtuvo la implementación más óptima.

Parece que la regla se reduce únicamente a alguien que siente que if(determineSomethingTrue)es más simple y más legible que if(!determineSomethingFalse). Y para ser justos, creo que tienen un cierto punto en que a menudo me parece if(!someTest)confuso * cuando hay una prueba alternativa de igual verbosidad y complejidad que volvería a ser cierta para la condición sobre la que queremos actuar. Sin embargo, en realidad, personalmente no encuentro nada que favorezca una sobre la otra de las dos alternativas que ofrece, y tal vez me inclinaría ligeramente hacia la primera si el predicado fuera más complicado.

* No es confuso ya que no entiendo, pero confuso como me preocupa que haya alguna razón sutil para la decisión que no entiendo, y se necesitan algunos saltos mentales para darse cuenta de que "no, simplemente decidieron hacerlo de esa manera, espera ¿para qué estaba mirando este bit de código otra vez? ... "

Puede encontrar que estos métodos de extensión hacen que su código sea más legible:

public static bool None<TSource>(this IEnumerable<TSource> source)
{
    return !source.Any();
}

public static bool None<TSource>(this IEnumerable<TSource> source, 
                                 Func<TSource, bool> predicate)
{
    return !source.Any(predicate);
}

Ahora en lugar de tu original

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

tu puedes decir

if (acceptedValues.None(v => v == someValue))
{
    // exception logic
}

Ambos tendrían un rendimiento idéntico porque ambos detienen la enumeración después de que se puede determinar el resultado: Any()en el primer elemento, el predicado pasado se evalúa truey All()en el primer elemento al que se evalúa el predicado false.

All cortocircuitos en el primer no partido, por lo que no es un problema.

Un área de sutileza es que

 bool allEven = Enumerable.Empty<int>().All(i => i % 2 == 0); 

Es verdad. Todos los elementos de la secuencia son pares.

Para más información sobre este método, consulte la documentación de Enumerable.All .

All()determina si todos los elementos de una secuencia satisfacen una condición.
Any()determina si algún elemento de una secuencia cumple la condición.

var numbers = new[]{1,2,3};

numbers.All(n => n % 2 == 0); // returns false
numbers.Any(n => n % 2 == 0); // returns true

De acuerdo a este enlace

Cualquiera: comprueba al menos una coincidencia

Todos: comprueba que todos coinciden

Como otras respuestas han cubierto bien: no se trata de rendimiento, se trata de claridad.

Hay un amplio soporte para sus dos opciones:

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

Pero creo que esto podría lograr un apoyo más amplio :

var isValueAccepted = acceptedValues.Any(v => v == someValue);
if (!isValueAccepted)
{
    // exception logic
}

Simplemente calcular el booleano (y nombrarlo) antes de negar cualquier cosa me aclara mucho esto.

Si echas un vistazo a la fuente Enumerable , verás que la implementación de Anyy Allestá bastante cerca:

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (predicate(element)) return true;
    }
    return false;
}

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (!predicate(element)) return false;
    }
    return true;
}

No hay forma de que un método sea significativamente más rápido que el otro, ya que la única diferencia radica en una negación booleana, por lo que prefiere la legibilidad sobre la ganancia de rendimiento falso.