Fuerza LINQ a no retrasar la ejecución

Question

De hecho, esta es la misma pregunta que este post:

How can I make sure my LINQ queries execute when called in my DAL, not in a delayed fashion?

Pero ya que él no ha explicado por qué él quería, la cuestión parece haber sido Pasó un poco. Aquí está mi problema similar pero mejor explicado:

Tengo un puñado de hilos en dos tipos (ignorando los hilos de UI por un momento). Hay un tipo de subproceso de "recopilación de datos" y un tipo de subproceso de "cómputo". Los hilos de recopilación de datos son lentos. Hay una gran cantidad de datos para ser examinados a través de una variedad de lugares. Los hilos de cálculo son comparativamente rápidos. El modelo de diseño hasta este punto es enviar subprocesos de recopilación de datos para encontrar datos, y cuando se completan pasan los datos para su cálculo.

Cuando codifiqué mi recopilación de datos en Linq terminé alzando parte de esa lentitud de nuevo en mis hilos de cálculo. Ahora hay elementos de datos que no se resuelven por completo hasta que se usan durante el cálculo, y eso es un problema.

Me gustaría obligar a Linq a terminar su trabajo en un momento dado (fin del enunciado? Fin del método? "Por favor termine, maldito" método de llamada) para que sepa que no voy a pagar más tarde en. Agregar ".ToList()" al final de Linq es 1. incómodo, y 2. se siente como algo de boxeo que está a punto de ser desempaquetado en otro hilo momentáneamente de todos modos.

Answer 1

No estaría boxeando nada, estaría almacenando los resultados.

El uso de ToList() es básicamente el camino a seguir si realmente desea los datos. A menos que esté listo para usar los datos de inmediato, tiene que ser almacenado en el buffer en algún lugar, ¿no es así? Una lista es solo una manera conveniente de hacerlo.

La alternativa es hacer el procesamiento en ese momento y también - utilice los datos mientras lo produce, con entusiasmo. No seguí los diferentes hilos de la cosa, por lo que no está claro si eso podría ayudarte, pero esas son básicamente las opciones disponibles para ti, hasta donde puedo ver.

Esto es en realidad un tanto explícito en su descripción:

El modelo de diseño hasta este punto es para enviar hilos de recopilación de datos fuera a datos de encontrar, y cuando están completa pase los datos para computación.

Calling ToList() básicamente cambia lo regrese de "una consulta que puede recuperar los datos cuando se le preguntó a" a "los datos en sí, tamponada en una lista".

Answer 2

¿Puede explicar más por qué .ToList no es aceptable? Mencionaste boxeo y unboxing, pero esos son temas completamente no relacionados.

Parte de forzar una consulta LINQ para completar en la demanda necesita almacenar los resultados. De lo contrario, para volver a ver los resultados, tendría que volver a consultar la consulta. .ToList logra esto de manera eficiente almacenando los elementos en un List<T>.

Es posible almacenar los elementos en prácticamente cualquier otra estructura de datos de estilo de colección con varias concesiones que se adapten mejor a sus necesidades.

Answer 3

Hay una propiedad LoadOptions en la clase DataContext que podría ayudarlo a obtener los datos con más entusiasmo.

Si no, puede usar unos pocos ToList() 's colocados astutos.

Answer 4

Sé que este hilo es viejo ... de todos modos, divertido que nadie mencionó .ToLast() todavía. Estoy haciendo algo donde linq no es mucho más que un foreach glorificado que maneja algunos efectos secundarios en los que realmente no me importa el resultado de la consulta ... así que no quería asignar más memoria falsa de la necesaria.