Count 속성 대 Count () 메서드?


85

컬렉션으로 작업하면 개체 수를 가져 오는 두 가지 방법이 있습니다. Count(속성) 및 Count()(방법). 주요 차이점이 무엇인지 아는 사람이 있습니까?

내가 틀렸을 수도 있지만 메서드가 컬렉션에 대해 일종의 쿼리를 수행 Count한다고 가정하기 때문에 항상 조건문 에서 속성을 사용합니다 . 그러나 그것은 추측입니다. 내가 틀렸다면 성능이 영향을 받을지 모르겠습니다.Count()Count

편집 : 호기심 Count()에서 컬렉션이 null이면 예외가 발생합니까? Count속성이 단순히 0을 반환 한다고 확신하기 때문 입니다.


7
둘 다 null 인 항목에 .연산자를 적용하려고하기 때문에 둘 다 null 컬렉션에 대해 예외를 throw합니다 .
— AaronLS

답변:


109

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;
    }
}

10
이것을 리버스 엔지니어링하기 위해 주도권을 잡은 +1은 매우 유용합니다.
— 다항식

7
그러나 3.5 Count()에서는 비 제네릭 ICollection인터페이스를 확인하지 않습니다 . 이것은 .NET 4에서만 추가되었습니다. 3.5와 4 모두 일반 ICollection<T>인터페이스를 확인합니다 .
— thecoop

2
요소가없는 시퀀스에서 count를 호출하면 예외가 발생합니다. 그러나 Count ()는 잘 작동합니다.
— amesh 2013-08-13

33

성능은 둘 중 하나를 선택하는 유일한 이유입니다. 선택 .Count()은 코드가 더 일반적임을 의미합니다. 더 이상 컬렉션을 생성하지 않는 일부 코드를 리팩토링 한 적이 있지만 대신 IEnumerable과 같은 좀 더 일반적인 코드를 리팩토링했지만 다른 코드는에 의존 .Count하고 .Count(). .Count()어디에서나 사용하도록 지적 하면 코드는 더 재사용 및 유지 관리가 가능할 것입니다. 일반적으로 더 일반적인 인터페이스를 사용하는 것이 최선의 방법입니다. 더 일반적인 것은 더 많은 유형으로 구현되는 더 단순한 인터페이스를 의미하므로 코드 간의 호환성이 향상됩니다.

내가 .Count()작성하는 코드의 재사용 가능성을 더 많이 다루는 다른 고려 사항이 있다고 말하는 것입니다.


2
+1 토론에 대한 귀중한 추가. 내가 유지하는 일부 코드는 .Count 속성이 HtmlAgilityPack의 버전 업그레이드에서 살아남지 못했기 때문에 방금 중단되었습니다.
— Dan Solovay

1
그것은 양날의 검일 수 있습니다. 언젠가 누군가가 IEnumerable을 진정한 제너레이터로 수정하려고하면 어떨까요? 상기 찾는 것은 .Count ()가 열거 여러 번 반복 될 수 있다고 가정 어디 곳을 많이 볼 코드베이스
— bashrc에를

@bashrc 참. 개발자의 코드 변경과 프레임 워크 코드 변경을 고려한다면 개발자 코드가 변경 될 가능성이 더 큽니다. 그런 종류의 변화가 프레임 워크에서 이루어 졌다면 많은 것을 깨뜨릴 것입니다. 전통적으로 이러한 경우 개발자가 원하는대로 마이그레이션 할 수 있도록 새로운 컬렉션 / 인터페이스를 도입합니다.
— AaronLS

20

이 .Count()메서드 는 충분히 똑똑하거나 문제의 유형에 대해 알고있을 수 있으며, 그렇다면 기본 속성을 사용할 수 있습니다 .Count.

다시 말하지만 그렇지 않을 수도 있습니다.

컬렉션에 .Count속성 자체 가있는 경우 성능과 관련하여 최선의 선택이 될 것이라고 가정하는 것이 안전하다고 생각합니다 .

는 IF .Count()방법은 컬렉션에 대해 알고하지 않습니다, 그것은 O (N) 작업이 될 것이다, 그 위에 열거됩니다.


3
Count속성을 사용하는 것이 더 좋을 수 있지만 사용 Count()방법 ICollection<T>.Count은 여기에 설명되어 있습니다. msdn.microsoft.com/en-us/library/bb338038(v=vs.110).aspx
— nawfal

당신이 거의 모든 것을 어떻게 아는지 모르겠습니다.
— snr

5

Count()method는의 각 요소를 반복 IEnumerable<>하고 얼마나 많은 요소가 있는지 반환하는 확장 메서드입니다 . 의 인스턴스 IEnumerable가 실제로 List<>이면 Count모든 요소를 ​​반복하는 대신 속성 을 반환하도록 최적화되어 있습니다.


List <>가있는 경우에도 Count () 메서드를 사용하여 코드를보다 일반적으로 유지합니다. 특정 컬렉션 구현이 필요하지 않은 IEnumerable <>을 사용하도록 클래스를 리팩토링 할 때 좋습니다.
— AntonioR

3

Count()LINQ의 확장 메서드가 있는지 여부- 실제 .NET 컬렉션 개체의 Count속성입니다 List.

따라서 Count()컬렉션 / 쿼리 가능한 개체를 열거하기 때문에 거의 항상 느립니다. 목록, 대기열, 스택 등에서 Count. 또는 배열의 경우- Length.


3

짧은 버전 : Count속성과 Count()방법 중에서 선택할 수있는 경우 항상 속성을 선택합니다.

차이점은 주로 운영 효율성에 있습니다. Count속성 을 노출하는 모든 BCL 컬렉션 은 O (1) 방식으로 수행합니다. 그러나이 Count()방법은 O (N)의 비용이들 수 있으며 종종 그렇게 될 것입니다. 일부 구현에 대해 O (1)에 시도하고 가져 오는 몇 가지 검사가 있지만 결코 보장되지는 않습니다.


이 답변이 count 속성을 사용하는 것이 더 합리적이라고 생각합니다
— AT

3

Count또는 Length속성 이있는 경우 Count()일반적으로 전체 컬렉션을 반복하여 포함 된 요소 수를 계산하는 메서드보다 항상 속성을 선호해야합니다 . Count()예를 들어 메서드가 LINQ to SQL 또는 LINQ to Entities 소스에 대한 경우는 예외입니다.이 경우 데이터 원본에 대해 개수 쿼리를 수행합니다. 그럼에도 불구하고 Count재산 이 있다면 할 일이 적기 때문에 그것을 선호 할 것입니다.


3

이 Count()메서드는 모든 IEnumerable<>. Count()메서드가 전체 컬렉션을 반복하여 개수를 찾을 것으로 예상 할 수 있지만 LINQ 코드에는 실제로 Count 속성이 있는지 여부를 감지하고 사용하는 경우이를 감지하기위한 몇 가지 최적화가 있습니다.

따라서 둘 다 거의 동일한 작업을 수행해야합니다. Count 속성은 유형 검사가 필요하지 않기 때문에 약간 더 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.