Работая с коллекцией, у меня есть два способа получить количество объектов; Count
(свойство) и Count()
(метод). Кто-нибудь знает, в чем основные отличия?
Возможно, я ошибаюсь, но я всегда использую это Count
свойство в любых условных операторах, потому что предполагаю, что Count()
метод выполняет какой-то запрос к коллекции, где as Count
должно быть уже назначено до того, как я «получил». Но это предположение - я не знаю, повлияет ли на производительность, если я ошибусь.
РЕДАКТИРОВАТЬ: Тогда из любопытства вызовет Count()
исключение, если коллекция равна нулю? Потому что я почти уверен, что Count
свойство просто возвращает 0.
.
оператор к чему-то, что имеет значение NULL.Ответы:
Декомпиляция источника для
Count()
метода расширения показывает, что он проверяет, является ли объектICollection
(общим или другим), и если да, просто возвращает базовоеCount
свойство:Итак, если ваш код обращается
Count
вместо вызоваCount()
, вы можете обойти проверку типов - теоретический выигрыш в производительности, но я сомневаюсь, что он будет заметным!// System.Linq.Enumerable public static int Count<TSource>(this IEnumerable<TSource> source) { checked { if (source == null) { throw Error.ArgumentNull("source"); } ICollection<TSource> collection = source as ICollection<TSource>; if (collection != null) { return collection.Count; } ICollection collection2 = source as ICollection; if (collection2 != null) { return collection2.Count; } int num = 0; using (IEnumerator<TSource> enumerator = source.GetEnumerator()) { while (enumerator.MoveNext()) { num++; } } return num; } }
источник
Count()
не проверяется неуниверсальныйICollection
интерфейс. Это было добавлено только в .NET 4. Обе версии 3.5 и 4 проверяют наличие универсальногоICollection<T>
интерфейса.Производительность - лишь одна из причин выбрать то или иное. Выбор
.Count()
означает, что ваш код будет более общим. У меня были случаи, когда я реорганизовал некоторый код, который больше не создавал коллекцию, а вместо этого делал что-то более общее, например IEnumerable, но в результате другой код ломался, потому что он зависел,.Count
и мне приходилось менять его на.Count()
. Если бы я решил использовать его.Count()
везде, код, вероятно, можно было бы использовать повторно и поддерживать. Обычно лучше всего использовать более общие интерфейсы, если вам это удается. Под более общим я подразумеваю более простой интерфейс, который реализуется большим количеством типов и, таким образом, обеспечивает большую совместимость кода.Я не говорю,
.Count()
что лучше, я просто говорю, что есть другие соображения, которые больше касаются повторного использования кода, который вы пишете.источник
.Count()
Метод может быть достаточно умны, или знать о типе в вопросе, и если да, то он может использовать основную.Count
собственность.Опять же, может и нет.
Я бы сказал, можно с уверенностью предположить, что если у коллекции есть
.Count
свойство, это будет вашим лучшим выбором, когда дело доходит до производительности.Если
.Count()
метод не знает о коллекции, он выполнит перечисление по ней, что будет операцией O (n).источник
Count
свойства могло бы быть лучше, но использованиеCount()
методаICollection<T>.Count
как бы задокументировано здесь: msdn.microsoft.com/en-us/library/bb338038(v=vs.110).aspxCount()
Метод - это метод расширения, который выполняет итерацию по каждому элементуIEnumerable<>
и возвращает количество имеющихся элементов. Если экземплярIEnumerable
действительно является aList<>
, значит, он оптимизирован для возвратаCount
свойства вместо повторения всех элементов.источник
Count()
существует как метод расширения от LINQ -Count
это свойствоList
s, реальных объектов коллекции .NET.Таким образом,
Count()
почти всегда будет медленнее, поскольку он будет перечислять объект коллекции / запроса. В списке, очереди, стеке и т. Д. ИспользуйтеCount
. Или для массива -Length
.источник
Краткая версия: если у вас есть выбор между
Count
свойством иCount()
методом, всегда выбирайте свойство.Разница в основном заключается в эффективности работы. Все коллекции BCL, которые предоставляют
Count
свойство, делают это способом O (1). Однако этотCount()
метод может стоить и часто будет стоить O (N). Есть несколько проверок, чтобы попытаться получить O (1) для некоторых реализаций, но это никоим образом не гарантируется.источник
Если есть свойство
Count
илиLength
, вы всегда должны предпочесть егоCount()
методу, который обычно выполняет итерацию всей коллекции для подсчета количества элементов внутри. Исключениями могут бытьCount()
случаи, когда метод относится к источнику LINQ to SQL или LINQ to Entities, например, и в этом случае он будет выполнять запрос подсчета для источника данных. Даже тогда, если естьCount
собственность, вы бы предпочли ее, поскольку у нее, вероятно, меньше работы.источник
Это
Count()
метод LINQ, который работает с любымиIEnumerable<>
. Вы ожидаете, чтоCount()
метод будет перебирать всю коллекцию, чтобы найти счетчик, но я считаю, что код LINQ действительно имеет некоторые оптимизации, чтобы определить, существует ли свойство Count, и если да, используйте его.Так что они оба должны делать почти одинаковые вещи. Свойство Count, вероятно, немного лучше, поскольку здесь не требуется проверка типа.
источник