Sebelum Linq, kita biasanya menggunakan metode berikut untuk menentukan apakah koleksi tidak kosong, yaitu koleksi berisi elemen:
Dengan menggunakan atribut Length atau Count, tidak ada masalah dengan penulisan di atas.
Tetapi di era Linq, metode ekstensi Enumerable.Count "menyatukan" properti Length dan Count, menghasilkan cara penulisan berikut untuk menilai non-nullity:
Tulisan ini baik-baik saja dan berfungsi dengan baik, tetapi dapat menyebabkan masalah kinerja yang sangat serius.
Perhatikan bahwa itu mungkin, belum tentu, dan jika metode di atas diteruskan sebagai Array<T>, List, atau Collection<T>, tidak akan ada masalah.
Jadi kapan ada yang salah? Mari kita lihat metode berikut:
Saat dipanggil:
Kecepatan eksekusi akan cukup lambat, dan butuh waktu sekitar 70 detik bagi komputer saya untuk mengeksekusi sumbernya. Hitung () > 0。
Jika Anda menganalisisnya, Anda akan menemukan bahwa pengembalian hasil i di baris 5 kode GetNums mengeksekusi int. MaxValue, apakah perlu?
Faktanya, selama kita mengembalikan satu elemen, kita dapat menyimpulkan bahwa himpunan tersebut tidak kosong, dan tidak perlu mengembalikan semua elemen sama sekali.
Jadi bagaimana cara menilai? Kita dapat menggunakan metode ekstensi Enumerable.Any:
Ubah metode SomeAction sebagai berikut:
Panggil lagi dan Anda akan menemukan bahwa waktu eksekusi dapat diabaikan.
Singkatnya, Count() > 0 pasti akan memiliki masalah kinerja ketika menghadapi pengembalian yeild.
|
Diposting pada 12/10/2017 13.25.01
|
|
|
|
