c# - unity - Forzar a Linq a no retrasar la ejecución
timer sleep c# (4)
De hecho, esta es la misma pregunta que esta publicación:
¿Cómo puedo asegurarme de que mis consultas LINQ se ejecuten cuando se las llama en mi DAL, y no de manera diferida?
Pero como no explicó por qué lo quería, la pregunta parece haberse pasado un poco. Aquí está mi problema similar pero mejor explicado:
Tengo un puñado de hilos en dos tipos (ignorando los hilos de la interfaz de usuario por un momento). Hay un tipo de subproceso de "recopilación de datos" y un tipo de subproceso de "cálculo". Los hilos de recopilación de datos son lentos. Hay una gran cantidad de datos que se pueden analizar desde una variedad de lugares. Los hilos de cálculo son comparativamente rápidos. El modelo de diseño hasta este punto es enviar hilos de recopilación de datos para encontrarlos, y cuando estén completos, pase los datos para su cálculo.
Cuando codifiqué mi recopilación de datos en Linq, terminé por subir algo de esa lentitud a 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 forzar a Linq a terminar su trabajo en un momento dado (¿fin de la declaración? ¿Fin del método? "Por favor, termine, maldita sea", llame al método) para que sepa que no lo pagaré más adelante. Agregar ".ToList ()" al final de Linq es 1. incómodo, y 2. se siente como encajonar algo que está a punto de desempaquetarse en otro hilo momentáneamente de todos modos.
¿Puedes explicar más por qué .ToList no es aceptable? Mencionó boxeo y unboxing, pero esos son temas completamente no relacionados.
Parte de forzar una consulta LINQ para completar bajo demanda requiere el almacenamiento de los resultados. De lo contrario, para volver a ver los resultados, tendría que volver a procesar la consulta. .ToList logra esto de manera eficiente al almacenar los elementos en una List<T> .
Es posible almacenar los elementos en prácticamente cualquier otra estructura de datos de estilo de colección con diversos compromisos que puedan satisfacer mejor sus necesidades.
Hay una propiedad LoadOptions en la clase DataContext que podría ayudarlo a obtener los datos con mayor entusiasmo.
De lo contrario, podría usar algunos ToList() colocados de forma inteligente.
No estarías boxeando nada, estarías amortiguando 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 inmediatamente, tiene que estar almacenado en algún lugar , ¿no es así? Una lista es solo una forma conveniente de hacerlo.
La alternativa es hacer el procesamiento en ese momento y también allí: use los datos a medida que los produce, con entusiasmo. No seguí los distintos hilos, por lo que no me queda claro si eso te ayudaría, pero esas son básicamente las opciones disponibles para ti, por lo que puedo ver.
Esto es en realidad algo explícito en su descripción:
El modelo de diseño hasta este punto es enviar hilos de recopilación de datos para encontrarlos, y cuando estén completos, pase los datos para su cálculo.
Llamar a ToList() básicamente cambia lo que devuelve de "una consulta que puede recuperar los datos cuando se le pide que" a "los datos en sí mismos, almacenados en una lista".
Sé que este hilo es viejo ... de todos modos, gracioso, nadie mencionó .ToLast () todavía. Estoy haciendo algo en el que linq no es mucho más que un glorificado para cada persona que produce 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 lo necesario.