Подтвердить что ты не робот

Метод count count vs Count()?

Работа с коллекцией У меня есть два способа получить количество объектов; Count (свойство) и Count() метод. Кто-нибудь знает, какие ключевые отличия? Возможно, я ошибаюсь, но я всегда использую свойство Count в любых условных операторах, потому что я предполагаю, что метод Count() выполняет какой-то запрос против коллекции, где, как граф, должно быть, был назначен до того, как я "получил". Но это предположение - я не знаю, повлияет ли производительность, если я ошибаюсь.

ИЗМЕНИТЬ: Из любопытства, будет ли Count() выдавать исключение, если коллекция равна нулю? Поскольку я уверен, что свойство Count просто возвращает 0.

4b9b3361

Ответ 1

Декомпиляция источника для метода расширения 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;
    }
}

Ответ 2

Производительность - одна из причин выбора того или другого. Выбор .Count() означает, что ваш код будет более общим. У меня были случаи, когда я реорганизовал какой-то код, который больше не создавал коллекцию, а вместо этого стал чем-то более общим, например IEnumerable, но другой код сломался, потому что он зависел от .Count, и мне пришлось изменить его на .Count(), Если бы я попытался использовать .Count() всюду, код, скорее всего, был бы более многоразовым и поддерживаемым. Обычно предпочитая использовать более общие интерфейсы, если вам это удастся, это ваш лучший выбор. Более общий, я имею в виду более простой интерфейс, который реализуется более типами, и, таким образом, вы получаете большую совместимость между кодом.

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

Ответ 3

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

Тогда это может и не быть.

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

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

Ответ 4

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

Ответ 5

Если есть свойство Count или Length, вы всегда должны использовать метод Count(), который обычно выполняет итерацию всей коллекции, чтобы подсчитать количество элементов внутри. (Исключение было бы тогда, когда метод Count() относится, например, к источнику Linq to SQL или Linq to Entities, и в этом случае он будет выполнять запрос счетчика к источнику данных. Даже тогда, если есть свойство Count, вы бы хочу предпочесть это, так как у него, вероятно, меньше работы.)

Ответ 6

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

Поэтому они должны делать почти одинаковые вещи. Свойство Count, вероятно, немного лучше, поскольку там не требуется проверка типа.

Ответ 7

Короткая версия: если у вас есть выбор между свойством Count и Count(), всегда выбирайте свойство.

Разница в основном связана с эффективностью операции. Все коллекции BCL, которые выставляют свойство Count, делают это способом O (1). Метод Count(), хотя может и часто будет стоить O (N). Есть некоторые проверки, чтобы попытаться получить его в O (1) для некоторых реализаций, но это ни в коем случае не гарантируется.

Ответ 8

Count() существует как метод расширения из LINQ - Count является свойством в List s, действительными объектами коллекции .NET.

Таким образом, Count() будет почти всегда медленнее, так как он будет перечислять объект collection/queryable. В списке, в очереди, в стеке и т.д. Используйте Count. Или для массива - Length.