¿Importa el orden de las funciones LINQ?

Básicamente, como dice la pregunta ... ¿importa el orden de las funciones LINQ en términos de rendimiento ? Obviamente, los resultados tendrían que ser idénticos aún ...

Ejemplo:

myCollection.OrderBy(item => item.CreatedDate).Where(item => item.Code > 3);
myCollection.Where(item => item.Code > 3).OrderBy(item => item.CreatedDate);

Ambos me devuelven los mismos resultados, pero están en un orden LINQ diferente. Me doy cuenta de que reordenar algunos artículos dará como resultado resultados diferentes, y eso no me preocupa. Mi principal preocupación es saber si, al obtener los mismos resultados, los pedidos pueden afectar el rendimiento. Y no solo en las 2 llamadas LINQ que hice (OrderBy, Where), sino en cualquier llamada LINQ.

Dependerá del proveedor LINQ en uso. Para LINQ to Objects, eso ciertamente podría marcar una gran diferencia. Supongamos que en realidad tenemos:

var query = myCollection.OrderBy(item => item.CreatedDate)
                        .Where(item => item.Code > 3);

var result = query.Last();

Eso requiere que toda la colección se ordene y luego se filtre. Si tuviéramos un millón de elementos, solo uno de los cuales tuviera un código mayor que 3, estaríamos perdiendo mucho tiempo ordenando resultados que se desecharían.

Compare eso con la operación inversa, filtrando primero:

var query = myCollection.Where(item => item.Code > 3)
                        .OrderBy(item => item.CreatedDate);

var result = query.Last();

Esta vez solo estamos ordenando los resultados filtrados, que en el caso de muestra de "un solo elemento que coincide con el filtro" será mucho más eficiente, tanto en tiempo como en espacio.

También podría marcar la diferencia en si la consulta se ejecuta correctamente o no. Considerar:

var query = myCollection.Where(item => item.Code != 0)
                        .OrderBy(item => 10 / item.Code);

var result = query.Last();

Está bien, sabemos que nunca dividiremos entre 0. Pero si realizamos el orden antes del filtrado, la consulta arrojará una excepción.

Si.

Pero exactamente cuál es esa diferencia de rendimiento depende de cómo el proveedor LINQ evalúe el árbol de expresión subyacente.

Por ejemplo, su consulta puede ejecutarse más rápido la segunda vez (con la cláusula WHERE primero) para LINQ-to-XML, pero más rápido la primera vez para LINQ-to-SQL.

Para averiguar con precisión cuál es la diferencia de rendimiento, lo más probable es que desee perfilar su aplicación. Sin embargo, como siempre con estas cosas, la optimización prematura no suele merecer el esfuerzo; es posible que descubra que otros problemas además del rendimiento de LINQ son más importantes.

En su ejemplo particular, puede marcar la diferencia en el rendimiento.

Primera consulta: su OrderByllamada debe recorrer en iteración toda la secuencia de origen, incluidos aquellos elementos en los que Codees 3 o menos. La Wherecláusula entonces también tiene que recorrer la totalidad ordenó secuencia.

Segunda consulta: la Wherellamada limita la secuencia a solo aquellos elementos donde Codees mayor que 3. La OrderByllamada sólo necesita atravesar la secuencia reducida devuelta por la Wherellamada.

En Linq-To-Objects:

La clasificación es bastante lenta y usa O(n)memoria. Wherepor otro lado, es relativamente rápido y usa memoria constante. Por lo tanto, hacerlo Whereprimero será más rápido y para colecciones grandes significativamente más rápido.

La presión de memoria reducida también puede ser significativa, ya que las asignaciones en el montón de objetos grandes (junto con su colección) son relativamente caras en mi experiencia.

Obviamente, los resultados tendrían que ser idénticos aún ...

Tenga en cuenta que esto no es realmente cierto; en particular, las siguientes dos líneas darán resultados diferentes (para la mayoría de proveedores / conjuntos de datos):

myCollection.OrderBy(o => o).Distinct();
myCollection.Distinct().OrderBy(o => o);

Vale la pena señalar que debe tener cuidado al considerar cómo optimizar una consulta LINQ. Por ejemplo, si usa la versión declarativa de LINQ para hacer lo siguiente:

public class Record
{
    public string Name { get; set; }
    public double Score1 { get; set; }
    public double Score2 { get; set; }
}


var query = from record in Records
            order by ((record.Score1 + record.Score2) / 2) descending
            select new
                   {
                       Name = record.Name,
                       Average = ((record.Score1 + record.Score2) / 2)
                   };

Si, por cualquier motivo, decidiera "optimizar" la consulta almacenando primero el promedio en una variable, no obtendría los resultados deseados:

// The following two queries actually takes up more space and are slower
var query = from record in Records
            let average = ((record.Score1 + record.Score2) / 2)
            order by average descending
            select new
                   {
                       Name = record.Name,
                       Average = average
                   };

var query = from record in Records
            let average = ((record.Score1 + record.Score2) / 2)
            select new
                   {
                       Name = record.Name,
                       Average = average
                   }
            order by average descending;

Sé que no mucha gente usa LINQ declarativo para objetos, pero es un buen motivo para pensar.

Depende de la relevancia. Suponga que si tiene muy pocos artículos con Código = 3, entonces el próximo pedido funcionará en un conjunto pequeño de colección para obtener el pedido por fecha.

Mientras que si tiene muchos artículos con la misma Fecha de creación, el siguiente pedido funcionará en un conjunto de colecciones más grande para obtener el pedido por fecha.

Entonces, en ambos casos habrá una diferencia en el rendimiento