LINQ: Nie Wszelkie vs All Nie

Question

Często Chcę sprawdzić, czy pod warunkiem wartość odpowiada jeden na liście (np podczas walidacji):

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

Ostatnio zauważyłem ReSharper pytając mnie do uproszczenia te zapytania do:

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

Oczywiście, to jest logicznie identyczne, być może nieco bardziej czytelne (jeśli zrobiłeś dużo matematyki), moje pytanie brzmi: czy to spowodować trafień wydajności?

Wydaje się, że powinno (to jest .Any() brzmi jak zwarcie, podczas gdy .All() brzmi jak nie), ale nie mam nic, co by to uzasadniało. Czy ktoś ma większą wiedzę na temat tego, czy zapytania rozwiążą ten sam problem, czy też ReSharper prowadzi mnie na manowce?

Answer 1

Implementacja All według ILSpy (tak jak w rzeczywistości poszedłem i spojrzałem, zamiast "dobrze, ta metoda działa trochę jak ..." Mogłabym zrobić, gdybyśmy dyskutowali raczej o teorii niż o wpływie).

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; 
} 

Wykonanie Any według 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; 
} 

Oczywiście, mogą pojawić się pewne nieznaczne różnice w IL produkowane. Ale nie, nie, nie ma. IL jest prawie taki sam, ale dla oczywistej inwersji zwracanej wartości true na dopasowaniu predykatów i zwracania wartości false w przypadku niezgodności predykatów.

Oczywiście tylko dla obiektów typu "linq-for-objects". Jest możliwe, że jakiś inny dostawca linq traktuje o wiele lepiej niż inny, ale jeśli tak było, to jest to dość losowe, które ma bardziej optymalną implementację.

Wydaje się, że reguła ta sprowadza się wyłącznie do kogoś, kto czuje, że if(determineSomethingTrue) jest prostszy i bardziej czytelny niż if(!determineSomethingFalse). I w uczciwości, myślę, że mają one pewien punkt w tym, że często uważam, że jest to mylące *, gdy istnieje alternatywny test o równej szczegółowości i złożoności, który powróciłby do stanu, w którym chcemy działać. Ale tak naprawdę, ja osobiście nie znajduję niczego, co mogłoby faworyzować jedną z dwóch oferowanych przez ciebie alternatyw, i być może pochyliłbym się nieznacznie w kierunku pierwszego, gdyby orzeczenie było bardziej skomplikowane.

* Nie mylić, jak w nie rozumiem, ale mylące, ponieważ martwię się, że istnieje jakiś subtelny powód decyzji, której nie rozumiem, i potrzeba kilku mentalnych przeskoków, aby zrozumieć, że "nie, oni właśnie postanowił zrobić to w ten sposób, należy odczekać co ja patrząc na ten kawałek kodu na raz ...”

Answer 2

All zwarcia na pierwszym niezgodnym, więc nie jest to problem.

Jednym z obszarów subtelności jest

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

jest prawdą. Wszystkie pozycje w sekwencji są równe.

Aby uzyskać więcej informacji na temat tej metody, zapoznaj się z dokumentacją dla Enumerable.All.

Answer 3

Oba miałyby identyczną wydajność, ponieważ zarówno wyliczenie przystanek po wynikach można stwierdzić - Any() na pierwszej pozycji przekazany orzecznik ocenia się true i All() na pierwszej pozycji orzecznik ocenia się false.

Answer 4

można znaleźć te metody przedłużania uczynić kod bardziej czytelny:

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); 
} 

teraz zamiast twojego oryginalnego

można powiedzieć

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

Answer 5

Według tego link

Dowolne - Sprawdza przynajmniej jeden mecz

Wszystkie - sprawdza, czy wszystkie mecze

Answer 6

All() określa, czy wszystkie elementy sekwencji spełniają warunek.
Any() określa, czy dowolny element sekwencji spełnia warunek.

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

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

Answer 7

Tak jak inne odpowiedzi są dobrze omówione: nie chodzi o wydajność, chodzi o jasność.

Istnieje szerokie poparcie dla obu opcji:

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

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

Ale myślę może to osiągnąć szersze poparcie:

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

Wystarczy obliczania Boolean (i nazywanie go) przed negując wszystko oczyszcza to wiele w moim umyśle.

Answer 8

Jeśli spojrzeć na Enumerable source zobaczysz, że realizacja Any i All jest dość blisko:

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; 
} 

Nie ma mowy, że jedna metoda jest znacznie szybsza niż inne, ponieważ tylko różnica polega na negacji boolowskiej, więc preferuj czytelność ponad fałszywą wygraną wydajności.