Retomamos FileOptimizer, y seguimos profundizando en sus entresijos, después de quedarnos en Cómo va FileOptimizer.
Realizando un análisis del código actual veo:
– Más de 500 Kb. de código fuente: C/C++, NSI (instalador), y HTML (ayuda en CHM): 22 archivos.
– Más de 150 Kb. de código fuente (excluyendo DFM y archivos de proyecto): 18 archivos.
– Más de 5.000 lineas de código.
– Más de 400 commits en SVN desde abril de 2014.
Parece increíble como poco a poco va creciendo, sin ir más lejos, el componente menos mantenido, su documentación, es ya del orden de 20 Kb. de texto en archivos HTML.
Pero lo más sorprendente, puede que sean las métricas de COCOMO donde según el coste estimado en Open Hub, donde partiendo de más de 50.000 lineas de código, representan 13 años/hombre de esfuerzo, valorado en 700.000$. Claro que es sólo una orientación, pues en el repositorio de código, se incluyen jsmin, gifsicle y jpegoptim, que sin ser de mi autoría, si que se incluyen a nivel binario x86 y x64 en FileOptimizer. Ocurre lo contrario con zRecompress, que aunque es mío, los fuentes no están incluidos en el repositorio, y por tanto no se tienen en cuenta.
Por lo demás, con más de 300.000 descargas hasta el momento, sólo de Sourceforge, y un estimado que podría ser del orden de 600.000 sumando todos los mirrors, puedo afirmar que seguimos en el camino correcto.
Lo vas a retomar?, o solo son estadísticas?
Abandonado no está. De hecho la última versión tiene apenas un mes, y hay algunas mejoras y actualizaciones ya disponibles en el repositorio: https://sourceforge.net/p/nikkhokkho/code/HEAD/tree/
Lo que si es cierto, es que llevo un tiempo que apenas puedo destinar esfuerzos a FileOptimizer, por lo que cambios mayores como el soporte multihilo o multiidioma, tendrán que seguir esperando.
Por lo demás, si que he ido implementando correcciones, actualizaciones, y funcionalidades nuevas menores.
que bien 🙂
¿Para qué quieres ponerle soporte multihilo? no está bien así?
Bueno, así está bastante bien. Lo que ocurre es que procesa solamente un archivo a la vez. La idea es detectar cuantas CPU/Cores tiene el equipo (esto es lo fácil), y entonces repartir el proceso en paralelo en cada uno de ellos.
Es decir, con 8 cores, procesaría 8 archivos a la vez, y por tanto sería 8 veces más rápido. El problema es que ésta, es la parte compleja, que requiere una reescritura casi completa de la lógica del programa.
En realidad llevo casi un año preparando el código para ello, pero es una tarea extensa.
suena interesante
A ver si tengo el tiempo suficiente de acabarlo de remodelar.
Esperamos verlo en funcionamiento, por cierto te envie un email con una duda, saludos.
Duda respondida Manuel.
Muchísimas gracias, saludos.
Gracias Nikko por tu programa File optimizer. Muy bueno. Por cierto hoy adquiri la actualizacion.
Gracias por tu apoyo a FileOptimizer Josue Aguilar.