Ya que estamos en el tema de BBDD y memoria. Ahora se está poniendo de moda las BBDD en memoria. Un poco más arriba decías que no es obligatorio el uso de BBDD y también dices que cargas las matrices en memoria. Pues pergunta, ¿has probado a crear un RAM disk y cargar todos los ficheros en RAM y trabajar desde RAM? Ventajas -> rapidísimo Inconveniente -> si se va la luz ... pierdes lo que tenías en RAM Para "medio-solventar" lo de la pérdida de datos, se puede hacer que copie los ficheros a disco cada poco tiempo, por ejemplo. Más cosas a tener en cuenta, tu aplicación es intensiva de: ¿CPU? ¿RAM? ¿I/O? ¿Bus? Lo digo porque si por sw has pasado de 3 meses a 4 horas, a lo mejor no lo puedes estrujar más vía sw, pero vía hw sí. A lo mejor ampliando RAM consigues darle un buen empujón. Piénsalo: es más barato añadir hw que horas de programación. OJO!! No quiero decir que cuando haya problemas se compre más hardware siempre. Sólo digo que es más barato y que a veces el código ya está optimizado y se puede hacer poco desde el punto de vista sw. ************** al principio era muy dependiente de I/O lo solucione pasando de una sola vez todas las tablas a matrices. ahora no es mas dependiente de I/O probe primero con el raid de raptor 2x74 raid0 eso ayudo muchisimo... luego con ramdrive, eso ayudo tambien muchisimo... luego por ultimo probe de pasar desde el raid a matrices y se termino el problema I/O tengo un c2q con 4GB de ram... estoy tirando 4 instancias de access simultaneas, para aprovechar los 4 cores. con 1,2GB de ram me sobra, incluso para tener todas las tablas en matrices. asi que voy a sacar 2GB y dejarlo para usar en un sistema de 32bits, que va algo mas rapido, con access claro... en este momento, creo, tira mas que nada de cpu y cache. trate de armar los bucles para que entren dentro de una cache de 1MB. en un amd64 de 1MB por nucleo va casi 3 veces mas rapido que en uno de 512K por nucleo. en un C2duo esta de fiesta. la velocidad de memoria no es importante. probe de poner la memoria en single channel en 400, en vez de dual channel en 800 y el rendimiento bajó 5% si se corta la luz, tengo ups... y aparte las tablas se leen una vez y solo se genera un registro con 5000 campos... todo lo demas es almacenamiento temporal, para ayudar a hacer los calculos que siguen. el tema es que quiero dejar access y pasar a algo mas efectivo, y no tan de alto nivel... se nota que esta pensado para ser facil, pero de eficiente nada. voy a ir por partes... esto me va a llevar un año largo pasar todo... asi que he optado por ir por partes primero lo paso todo a VB que es rapido de migrar, y me va a dar un 80% mas de rendimiento, asi por las pruebas preliminares y de a poco voy armando las funciones mas pesadas en C o C++. en C por lo poco que pude simular, tengo 3 veces el rendimiento que en VB... asi que estaria multiplicando por 5 mas o menos el rendimiento total. de todas maneras, hay partes que en C se pueden optimizar muchisimo, porque me da la opcion de procesar varios datos por sse en un ciclo de reloj. cuando termine eso, ya lo tendria casi casi listo para compilar para el sistema que sea, al menos la parte de calculos. y ahi recien podre ponerlo multiplataforma. yo queria hacerlo multiplataforma ya, pero es que no puedo sacarlo de produccion. Gracias a todos por su ayuda. me dejaron las cosas mucho mas claras de lo que hacer... porque me fueron tirando pequeñas cosas que me hicieron ver el problema en una forma mas amplia, y creo que pude encontrar la mejor solucion ahora es solo cuestion de tiempo para programarlo- --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org