AN ICOLLECTION знает количество элементов (подсчет), которое он содержит. Это не должно повторять какие-либо предметы, чтобы определить его. Возьмите, например, класс класса (который реализует ychollce ).

AN IENumerable не знает, сколько элементов он содержит. Вы должны перечислить весь список, чтобы определить количество элементов (счетчика).

Упаковка Щелк в операторе LINQ не делает его более эффективным. Независимо от того, как вы поворачиваете и поворачиваются, амоклек должен быть перечислен.

Edit 02-Feb-2010 :

На мой взгляд, есть как минимум два способа интерпретировать этот вопрос.

Почему метод расширения Select , когда вызвал экземпляр класса, который реализует ICollection , а не возвращать объект, который предоставляет свойство Count ; и почему метод расширения Count не проверяет это свойство, чтобы обеспечить производительность O (1), когда два {{ 1}} связаны цепочкой?

Эта версия вопроса не делает ложных предположений о том, как работают расширения Linq, и является правильным вопросом, поскольку вызов ICollection .Select.Count будет, в конце концов, всегда возвращайте то же значение, что и ICollection .Count . Вот как Мехрдад истолковал вопрос, на который он дал обстоятельный ответ.

Но Я прочитал вопрос как вопрос ...

Если метод расширения Count обеспечивает производительность O (1) для объекта класса , реализующего ICollection , почему обеспечивает производительность O (n) для возвращаемого значения Select метод расширения?

В этой версии вопроса существует ошибочное предположение: методы расширения Linq работают вместе, собирая небольшие коллекции одна за другой (в памяти) и выставляя их через интерфейс IEnumerable .

Если бы так работали расширения Linq, метод Select мог бы выглядеть примерно так:

public static IEnumerable<TResult> Select<T, TResult>(this IEnumerable<T> source, Func<T, TResult> selector) {
    List<TResult> results = new List<TResult>();

    foreach (T input in source)
        results.Add(selector(input));

    return results;
}

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

На самом деле, я считаю, что реализация метода Select намного ближе к чему-то вроде этого:

public static IEnumerable<TResult> Select<T, TResult>(this IEnumerable<T> source, Func<T, TResult> selector) {
    foreach (T input in source)
        yield return selector(input);

    yield break;
}

Это обеспечивает ленивую оценку и объясняет, почему свойство Count недоступен за время O (1) для метода Count .

Другими словами, в то время как Мехрдад ответил на вопрос , почему Select не был разработан иначе, чтобы Select.Count вел себя иначе , я предложил свой лучший ответ на вопрос , почему Select.Count ведет себя так же, как .

ОРИГИНАЛЬНЫЙ ОТВЕТ :

Побочные эффекты метода - это не ответ.

Согласно ответу Мехрдада:

На самом деле не имеет значения, что результат операции Select вычисляется лениво.

Я не куплюсь на это. Позвольте мне объяснить почему.

Для начала рассмотрим два очень похожих метода:

public static IEnumerable<double> GetRandomsAsEnumerable(int N) {
    Random r = new Random();

    for (int i = 0; i < N; ++i)
        yield return r.NextDouble();

    yield break;
}

public static double[] GetRandomsAsArray(int N) {
    Random r = new Random();

    double[] values = new double[N];
    for (int i = 0; i < N; ++i)
        values[i] = r.NextDouble();

    return values;
}

Хорошо, что делают эти методы? Каждый из них возвращает столько случайных удвоений, сколько желает пользователь (до int.MaxValue ).Имеет ли значение, лениво оценивается тот или иной метод? Чтобы ответить на этот вопрос, давайте взглянем на следующий код:

public static double Invert(double value) {
    return 1.0 / value;
}

public static void Test() {
    int a = GetRandomsAsEnumerable(int.MaxValue).Select(Invert).Count();
    int b = GetRandomsAsArray(int.MaxValue).Select(Invert).Count();
}

Можете ли вы угадать, что произойдет с этими двумя вызовами методов? Позвольте мне избавить вас от необходимости скопировать этот код и протестировать его самостоятельно:

Первая переменная , a , будет (после потенциально значительного количества времени) инициализирована как int.MaxValue (в настоящее время 2147483647). второй , b , скорее всего, будет прерван из-за исключения OutOfMemoryException .

Поскольку Select и другие методы расширения Linq вычисляются лениво, они позволяют вам делать то, что вы просто не смогли бы сделать иначе. Выше приведен довольно тривиальный пример. Но моя главная цель - оспорить утверждение о том, что ленивое вычисление не важно. Утверждение Мердада о том, что свойство Count «действительно известно с самого начала и может быть оптимизировано», на самом деле вызывает вопрос. Проблема может показаться простой для метода Select , но Select на самом деле не является чем-то особенным; он возвращает IEnumerable , как и остальные методы расширения Linq, и чтобы эти методы «знали» Count их возвращаемых значений , потребуются полные коллекции кэшироваться и, следовательно, запрещать ленивую оценку .

Ответ - ленивое вычисление.

По этой причине я должен согласиться с одним из первоначальных респондентов (чей ответ теперь, кажется, исчез), что ленивое вычисление действительно является здесь ответом. Идея о том, что необходимо учитывать побочные эффекты метода, на самом деле вторична, поскольку в любом случае это уже обеспечено как побочный продукт ленивой оценки.

Постскриптум: Я делал очень убедительные заявления и подчеркивал свои аргументы главным образом потому, что хотел четко сформулировать мои аргументы, а не из-за неуважения к другим ответам, в том числе к ответам Мехрдада, которые я считаю проницательными, но упускающими из виду отметка.