Implementando su propio LINQ & amp; IEnumerable < T > [cerrado]

Question

En un proyecto en el que estoy trabajando, hay colecciones realmente enormes (elementos 1M-1B), y las cosas se modifican principalmente como colecciones.

Es una aplicación en tiempo real, por lo que el rendimiento es primordial.

Para algunas de las operaciones, como Reverse, BinarySearch (¿posible?), etc. sufrirán más que otras como Select, etc.

¿Es factible implementar el propio IEnumerable con las posibles MoveNext, MovePrev, etc. y las extensiones LINQ implementadas que aprovechan estas ventajas?

Si esto va a suceder, sucederá al final del proyecto. Porque primero necesitamos que funcione, luego hacerlo más rápido.

En general, esto no debería ser demasiado trabajo, ¿verdad?

Answer 1

Definitivamente es posible crear su propia implementación de Enumerable , lo que podría suceder en casos especiales. Básicamente, desearía detectar sus propios tipos de colección (o posiblemente solo colecciones como List < T > ) y utilizar una implementación más eficiente cuando corresponda.

Tengo un proyecto de muestra que utilicé para demostrar " implementar LINQ to Objects en un hora " que le gustaría ver para ver ejemplos. No es una implementación completa y, en particular, es menos eficiente que el LINQ to Objects real, pero aún así puede resultarle interesante.

Alternativamente, puede encontrar que i4o (LINQ indexado) hace todo lo que necesita de forma inmediata: o que sería mejor contribuir a eso que comenzar desde cero. Vale la pena echarle un vistazo.

Solo recuerda que al final del día, LINQ es básicamente un diseño agradable junto con azúcar sintáctico. El compilador de C # no sabe nada especial sobre System.Linq.Enumerable , por ejemplo.

Answer 2

Si realmente quieres rendimiento, puedes hacer mucho. Recuerde que la siguiente selección:

var result = from element in collection
             where element.Id == id
             select element;

Compila como:

var result = collection.Where(element => element.Id == id);

Si crea el siguiente método para el tipo de collection , puede aprovechar el hecho de que la acción principal es la igualdad del miembro Id y manejar la solicitud de manera optimizada. Lo importante es identificar correctamente las operaciones críticas de rendimiento en su colección y elegir los algoritmos correctos (es decir, la complejidad) para realizarlos.

public IEnumerable<TElement> Where(Expression<Func<TElement, bool>> selector)
{
    // detect equality of the Id member and return some special value
}

Answer 3

Considere System.Linq.Enumerable.Reverse (): este método enumera completamente IEnumerable antes de devolver el primer resultado.

Si su consulta es myCollection.Reverse (). Take (10), y su colección tiene miles de millones de elementos, es una idea horrible enumerar los miles de millones de elementos para obtener 10.

Si proporcionó un método Reverse en su propio tipo, podría proporcionar una mejor implementación que simplemente retroceda sobre la colección (posiblemente por índice).

La clave para esto es proporcionar su propio tipo donde controla las implementaciones. No puede utilizar las implementaciones que funcionan para todos los IEnumerable < T > porque esas implementaciones no aprovecharán al máximo las capacidades de su tipo de colección personalizada.

Answer 4

  

¿Es factible implementar el propio   IEnumerable con posibles MoveNext,   MovePrev, etc. y su propio LINQ implementado   extensiones que aprovechan   estos?

IEnumerable (o más correctamente, IEnumerator ) no tiene MovePrev . Podría definir una interfaz:

public interface IReversable<T> : IEnumerable<T>
{
    IEnumerator<T> GetReverseEnumerator();
}

Esto podría ser implementado por cualquier contenedor que admita una enumeración inversa eficiente.

Entonces podría escribir una sobrecarga de Reverse (el método de extensión) para trabajar con esta nueva interfaz, y las clases de colección que implementan la interfaz, etc. Y luego tendría que usar esa colección clases en lugar de las estándar como List < T > .

Pero (no tengo el Reflector a mano para verificar) puede ser que el Reverse incorporado sea lo suficientemente inteligente como para hacer las cosas de manera rápida si puede obtener la IList interfaz de la colección, que optimizaría los casos más comunes de todos modos.

Por lo tanto, puede que no haya mucho sentido en este tipo de enfoque.