#1407 closed defect (fixed)
Tiempo excesivo en el import de BSR
Reported by: | Owned by: | Víctor de Buen Remiro | |
---|---|---|---|
Priority: | high | Milestone: | Mantainance |
Component: | BSR | Version: | head |
Severity: | critical | Keywords: | |
Cc: | lmperez@…, cperez@…, inascimento@…, gschimidt@… |
Description
Hola MMS, estoy probando a construir modelos con un número de submodelos relativamente grande (más de 50), todos en fechado mensual. Y me estoy encontrando una seria dificultad ya que al estimar con estratégia BSR, la fase del import+parse me está tardando del orden de entre un 30% y un 40% del tiempo total del proceso.
La pregunta es, ¿sería factible eliminar esta fase? ¿podría bsr ser invocado de forma similar a como lo es Estimate, sin pasar por escritura de archivos?
Gracias de antemano
Change History (5)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 Changed 13 years ago by
Una parte importante del tiempo se empleaba en almacenar las matrices de regresión en archivos OIS comprimidos (.oza), debido a la excesiva sobrecarga de las cabeceras y al tiempo de compresión. Para evitarlo se han creado las funciones VMatWriteFile
y VMatReadFile
especializadas en el almacenamiento y recuperación de matrices virtuales (VMatrix) en ficheros binarios que usan los métodos internos de OIS en un único fichero secuencial con una cabecera mínima y sin compresión.
También se han reducido las trazas de importación que en TOLBase tomaban un tiempo excesivo en estos casos de muchos submodelos pequeños. Esas trazas se pusieron en su día para monitorizar el proceso de parseo que hace ya tiempo que se puede dar por bueno.
BSR no necesita Import ni ficheros de ningún tipo, lo que necesita es una estructura de datos @BSR.ModelDef tremendamente compleja, con matrices las matrices sparse del bloque lineal y la información del resto de bloque indexada sobre dichas matrices, para que pueda ser manejada eficientemente en los algoritmos internos.
El parser basado en ficheros ascii .bsr se ocupa de cerciorarse de que la información es congruente y de crear la estructura @BSR.ModelDef. También está pensado para cuando seamos capaces de paralelizar un modelo en varias máquinas pues en tal caso la definición podría no caber en RAM en una misma máquina, y cada una cargaría los trozos que le tocaran.
MMS quizás podría crear esa @BSR.ModelDef directamente en RAM ya que se supone que ya se ha cerciorado previamente de la congruencia, pero como ya digose trata de una estructura muy compleja.
Tampoco tengo nada claro que eso realmente ahorrara un tiempo significativo. Habría que ver qué parte del tiempo se lleva cada proceso
Los dos primeros procesos es lo que se suele llamar Import, pero sólo una parte muy pequeña está programada en BysMcmc, lo gordo forma parte de MMS. En cuanto al parser me extrañaría que tardara demasiado en comparación con el import.