Przed Linq zwykle stosowaliśmy następującą metodę, aby określić, czy kolekcja jest niepusta, tzn. zawiera elementy:
Korzystając z atrybutu Długość lub Liczba, nie ma problemu z powyższym tekstem.
Jednak w erze Linq metoda rozszerzenia Enumerable.Count "ujednoczyła" właściwości Length i Count, co skutkowało następującym sposobem pisania oceniającym nie-nullity:
To pisanie jest w porządku i działa dobrze, ale może powodować poważne problemy z wydajnością.
Należy zauważyć, że jest to możliwe, niekoniecznie, i jeśli powyższa metoda zostanie przekazana jako tablica<T>, lista lub kolekcja, nie <T>będzie problemu.
Kiedy więc coś pójdzie nie tak? Przyjrzyjmy się następującym metodom:
Gdy zostaje wezwany:
Prędkość wykonania będzie dość wolna, a komputer potrzebował około 70 sekund, by wykonać źródło. Count() > 0。
Jeśli to przeanalizujesz, okażesz, że yield return i w linii 5 kodu GetNums wykonuje int. MaxValue, czy jest konieczna?
W rzeczywistości, dopóki zwracamy jeden element, możemy stwierdzić, że zbiór jest niepusty i nie ma potrzeby zwracania wszystkich elementów.
Jak więc ocenić? Możemy użyć metody rozszerzenia Enumerable.Any:
Zmodyfikuj metodę SomeAction w następujący sposób:
Zadzwoń jeszcze raz, a zobaczysz, że czas wykonania jest znikomy.
Podsumowując, Count() > 0 nieuchronnie będzie miał problemy z wydajnością, gdy napotka yeild return.
|
Opublikowano 12.10.2017 13:25:01
|
|
|
|
