Tal vez cuando leísteis FileOptimizer y la comunidad, tuvierais la impresión de que el desarrollo de File Optimizer, quedaría abandonado. No es en absoluto el caso, y sigue estando en una fase de desarrollo plenamente activo.
FileOptimizer, continúa evolucionando, y la prueba es la reciente versión 11, lanzada con importantes cambios y mejoras.
Para que os podáis hacer una idea, he tomado como base FileOptimizer 6.80, de abril de 2014, y que es la versión más antigua de código fuente que conservo en el repositorio, correspondiente a la r2. La he comparado con FileOptimizer 11.00 de septiembre de 2017, o sea 3 años y medio después.
Procedamos a comparar su código fuente. Excluyendo archivos de proyecto, instalador, ayuda, ni los PHP de soporte web, obtenemos que ha pasado de un total de 5.988 lineas de código en 2014, a 8.532 en 2017, un incremento que supone un 42%. Como guía, equivalen a unas 130 páginas A4 mecanografiadas en espacio sencillo.
Lineas de código (LOC)
| Archivo | FileOptimizer 6.80 | FileOptimizer 11.00 |
| FileOptimizer.cpp | 93 | 121 |
| FileOptimizerPCH1.h | 8 | 24 |
| Source\clsUtil.cpp | 790 | 1.158 |
| Source\clsUtil.h | 65 | 82 |
| Source\cppAbout.cpp | 136 | 110 |
| Source\cppAbout.h | 33 | 33 |
| Source\cppAbout.dfm | 742 | 380 |
| Source\cppMain.cpp | 1.752 | 3.413 |
| Source\cppMain.h | 197 | 312 |
| Source\cppMain.dfm | 1.070 | 1.184 |
| Source\cppOptions.cpp | 254 | 393 |
| Source\cppOptions.h | 74 | 127 |
| Source\cppOptions.dfm | 774 | 1.206 |
| TOTAL | 5.988 | 8.532 (+43%) |
En cuanto al peso del código fuente, obtenemos unos datos similares. 247.909 bytes en 2014, por 324.933 de 2017. Esto es, un aumento de un 31%.
Tamaño del código fuente (bytes)
| Archivo | FileOptimizer 6.80 | FileOptimizer 11.00 |
| FileOptimizer.cpp | 3.020 | 5.007 |
| FileOptimizerPCH1.h | 229 | 635 |
| Source\clsUtil.cpp | 25.545 | 39.332 |
| Source\clsUtil.h | 4.103 | 5.635 |
| Source\cppAbout.cpp | 3.508 | 3.786 |
| Source\cppAbout.h | 1.264 | 1.248 |
| Source\cppAbout.dfm | 45.888 | 20.140 |
| Source\cppMain.cpp | 61.136 | 129.360 |
| Source\cppMain.h | 8.506 | 13.945 |
| Source\cppMain.dfm | 55.247 | 54.364 |
| Source\cppOptions.cpp | 7.064 | 13.498 |
| Source\cppOptions.h | 2.328 | 3.935 |
| Source\cppOptions.dfm | 30.071 | 34.048 |
| TOTAL | 247.909 | 324.933 (+31%) |
Resulta curioso, que si analizamos únicamente el exterior, lo que se ve, puede que no tengamos esa misma percepción, pues el tamaño de los ejecutables, se ha reducido en estos 3 años. Ello se debe en primer lugar, a la eliminación de la interfaz por cinta de opciones o Ribbon que era exageradamente pesada. Pero también a las mejoras que suponen que C++ Builder, pueda compilar con un backend basado en CLang en vez de BCC.
No debemos olvidar el esfuerzo continuado en cuanto a limpieza, optimización y reutilización de código, que versión tras versión, va sufriendo FileOptimizer por mi parte.
Tamaño de los ejecutables (bytes)
| FileOptimizer 6.80 | FileOptimizer 11.00 | |
| Tamaño ejecutable x86 (bytes) -FileOptimizer32.exe- | 4.550.656 | 4.317.184 (-5%) |
| Tamaño ejecutable x64 (bytes) -FileOptimizer64.exe- | 9.024.000 | 7.936.512 (-12%) |
De este modo, puedo sentirme orgulloso. Versión tras versión, FileOptimizer añade más funciones, más capacidades, mayores prestaciones. Pero a diferencia de lo que ocurre en el resto del software, el peso, y la ligereza se mantienen a ralla.
Un proyecto estimado en 3 años/hombre de esfuerzo, llevado a cabo en 5 años naturales, representa también un buen indicador de productividad. Por otro lado, seguir en activo tras ese tiempo, nos demuestra no solamente que sigue siendo útil a día de hoy, y que aún no tiene digno rival, sino que su código fuente, es mantenible y de calidad.
Una rareza en software, por desgracia: que los ejecutables de las nuevas versiones pesen menos que los de las antiguas. Por cierto, ¿a qué se debe que el tamaño se doble cuando se compila para x64? ¿el direccionamiento, las cabeceras, los metadatos, o es simplemente por la forma de tratar la información el procesador? Es que si no recuerdo mal, cuando compilaba para 16 y 32 bytes, no me parece a mí que hubiese tanta diferencia, o al menos no tengo esa sensación.
Gracias bianamaran. Sabes que como usuario, yo también valoro la eficiencia, por lo que como desarrollador, debo hacer lo mismo o no sería consecuente.
En los principios de los 32 bits, la mayoría de compiladores, aún generaban algo de código de 16 bits, y sobre todo las librerías, seguían teniendo mucho código de 16 bits. Así que la diferencia, no era tanta.
Por otro lado, lo de que el código sea el doble de voluminoso, es algo de C++ Builder. Los chicos de Embarcadero, CodeGear, Inprise y Borland, nunca han sido demasiado eficientes. No se dónde estará la diferencia, supongo que en la VCL principalmente, pero no debería ser el doble. Suele rondar de un 25% a un 50% de incremento.
Si comparo otras cosas, que no usan C++ Builder ni Delphi, veo que PatchPE es 107 Kb en 32 bits, y 125 Kb. en 64 bits; SumatraPDFOpt es 1918 Kb en 32 bits, y 2166 en 64 bits; RLE64 66 Kb contra 71 Kb; GreatNews 1368 contra 1835; o incluso Lamark, que es Lazarus 455 vs 497. Imagino que el problema ocurrirá también con Delphi.
Para que te hagas una idea, estas son las diferencias de tamaño de instrucciones sencillas a nivel de código máquina:
Asignar un registro a 0:
– 16 bits: xor ax, ax (3 bytes).
– 32 bits: xor eax, eax (2 bytes).
– 64 bits: xor rax, rax (3 bytes).
Asignar un registro a 1:
– 16 bits: mov ax, 1 (4 bytes).
– 32 bits: mov eax, 1 (5 bytes).
– 64 bits: mov rax, 1 (7 bytes).
Leer un byte de memoria:
– 16 bits: mov di, [mem] (5 bytes).
– 32 bits: mov edi, [mem] (6 bytes).
– 64 bits: mov rdi, [mem] (8 bytes).
Que bueno la comparación con el código máquina, así se entiende todo mucho mejor. Gracias Guti
Excelente
Eres muy amable Bianamaran.
Gracias Manuel.
Hi!
I’m having troubles with FileOptimizer for some time now. The last working version for me is 9.20.1585 (x64), having Win10Pro x64, dealing with pdf-files. I’m using portable version of the program.
In short: FO will not flatten comments etc in pdf-files at all. They are accessible after the compression as they was before it. The compression ratio is worse (a lot) compared to the 9.20 version. FO skips gswin64c.exe too fast.
Regards
Thank you for your comment Highlander. Since this is my personal site, I will suggest you moving future discusions to the official forum at Sourceforge: https://sourceforge.net/p/nikkhokkho/discussion/
As stated in the changelog, since FileOptimizer 9.40 we are detecting layered PDF, and skipping them being procesed by Ghostcript. Currently this is the INI setting PDFSkipLayered and the checkbox in Options->PDF->Skip layered, so you can change this default behaviour.
If you are happy, please, consider making a donation: http://nikkhokkho.sourceforge.net/images/FileOptimizerDonate.html
Hola, me desculpe por espanol malo, pero pudeo hacer una suggestion? No me gusta Taboola. Es el peor de los peores de los ad providers. Me gustaria tener los ads para te dar dinero (muchas gracias por el software), pero no puedo con Taboola. Las images son horribles. Usted puede addicionar Outbrain o AdChoices o qualquer otro ad provider que no es tan…. asqueroso? Muchas gracias.
Thanks Josh.
I tried with Outbrain and they rejected my offer. I will take a look at Adchoices.
Gracias por su respuesta, y por el software! <3
Gracias Josh. Te informo que Adchoices ha rechazado mi candidatura. Hoy en día casi ninguna red de publicidad está interesada en apoyar el software libre.