Свойство Count против метода Count ()?

Работая с коллекцией, у меня есть два способа получить количество объектов; Count(свойство) и Count()(метод). Кто-нибудь знает, в чем основные отличия?

Возможно, я ошибаюсь, но я всегда использую это Countсвойство в любых условных операторах, потому что предполагаю, что Count()метод выполняет какой-то запрос к коллекции, где as Countдолжно быть уже назначено до того, как я «получил». Но это предположение - я не знаю, повлияет ли на производительность, если я ошибусь.

РЕДАКТИРОВАТЬ: Тогда из любопытства вызовет Count()исключение, если коллекция равна нулю? Потому что я почти уверен, что Countсвойство просто возвращает 0.

Декомпиляция источника для 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()означает, что ваш код будет более общим. У меня были случаи, когда я реорганизовал некоторый код, который больше не создавал коллекцию, а вместо этого делал что-то более общее, например IEnumerable, но в результате другой код ломался, потому что он зависел, .Countи мне приходилось менять его на .Count(). Если бы я решил использовать его .Count()везде, код, вероятно, можно было бы использовать повторно и поддерживать. Обычно лучше всего использовать более общие интерфейсы, если вам это удается. Под более общим я подразумеваю более простой интерфейс, который реализуется большим количеством типов и, таким образом, обеспечивает большую совместимость кода.

Я не говорю, .Count()что лучше, я просто говорю, что есть другие соображения, которые больше касаются повторного использования кода, который вы пишете.

.Count()Метод может быть достаточно умны, или знать о типе в вопросе, и если да, то он может использовать основную .Countсобственность.

Опять же, может и нет.

Я бы сказал, можно с уверенностью предположить, что если у коллекции есть .Countсвойство, это будет вашим лучшим выбором, когда дело доходит до производительности.

Если .Count()метод не знает о коллекции, он выполнит перечисление по ней, что будет операцией O (n).

Count()Метод - это метод расширения, который выполняет итерацию по каждому элементу IEnumerable<>и возвращает количество имеющихся элементов. Если экземпляр IEnumerableдействительно является a List<>, значит, он оптимизирован для возврата Countсвойства вместо повторения всех элементов.

Count()существует как метод расширения от LINQ - Countэто свойство Lists, реальных объектов коллекции .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, вероятно, немного лучше, поскольку здесь не требуется проверка типа.