viernes 22 de mayo de 2009

Tiempos de compilación en Java y la versión del NMake


En una KB estaba teniendo demoras en la compilación de varios minutos, lo cual no era para nada razonable.

Es una KB con GeneXus 9.0 U4, generando Java, y compilando con jikes de IBM y el nmake de Microsoft.

Analizando un poco, lo que encontré fue que cada vez que compilaba estaba copiando todas las clases al directorio del Tomcat. El .mak en cuestión hace referencia a más de 1.000 clases, con un tamaño de más de 500MB.

En otro PC, compilar el mismo objeto en la misma KB, no demoraba nada... Así que comparando las versiones de los ejecutables en cuestión, encontré que el que estaba distinto era el nmake.exe

La versión que yo tenía, era la 8.0.50727.762. La versión con la que funciona bien es la 7.10.3077.0...

Así que ahora por suerte volví a tiempos razonables de unos pocos segundos en la compilación.

Un tip: si alguien necesita ver que es lo que está haciendo la compilación, lo que hay que hacer es:
  1. en el archivo callmake.bat (en el directorio data002 o en el web según sea el caso), hay que comentar la primer línea que dice "@echo off"
  2. en el archivo .mak, cuando copia los archivos al directorio del Tomcat, lo hace con "@copy" que no imprime nada a pantalla; para ver lo que se está copiando hay que cambiarlos todos por "copy"
El callmake.bat no cambia a menos que se cambie de versión del generador, por lo que después hay que volver a dejarlo como estaba. El .mak cambia cuando cambia el árbol de llamadas, así que vuelve solo a su estado normal.
Publicado por a las 11:49
Etiquetas: ,

4 comentarios:

  1. Hola Marcos.

    yo casualmente hace poco anduve haciendo las mismas pruebas.

    Los nmake evaluados fueron:
    1.62.7022 - Microsoft SDK for Java
    7.10.3077 - Microsoft .NET SDK 1.1
    8.00.50727.42 - Microsoft .NET SDK 2.0

    No pude probar la versión del SDK del .NET 3.5 porque ahora forma parte del Windows SDK (tengo que ver de bajar ese SDK inmenso para instalarlo y ver si hay algún cambio)

    La verdad que en mi caso no encontré ese problema de los tiempos. (en una de esas la forma en que hice las pruebas hicieron que no se diera el mismo caso).

    Lo que pueda estar pasando es el método que utiliza Microsoft para evaluar si algún archivo de las dependencias fue cambiado (el timestamp)o sea, los @touch.

    En mi caso las evaluaciones que hice me dieron que los nmake más modernos tienen en cuenta las nuevas características de hardware (y uso de IO).
    De todas formas los tiempos de diferencia son mínimos (Porque el costo en la mayoría de los casos está en compilación y no en escaneo de archivos).

    ¿La KB de casualidad está en red?

    Acá hay un buen resumen de las cosas que pueden estar ocurriendo con el timestamp de los archivos y el nmake (es viejo el reporte pero en el fondo son los principales problemas) http://support.microsoft.com/kb/130615/en-us

    Mis pruebas fueron todas de forma local, por lo que en una de esas el tema de diferencia de fechas no me sucedió.
    ResponderEliminar
  2. Prueba ponerle al nmake el parámetro -d (Displays timestamps), en una de esas encuentras en donde está el problema.
    ResponderEliminar
  3. David: Leí tu artículo de los compiladores, pero esto no tenía nada que ver... Además estamos con la VM 1.4.2 y con jikes funciona bien.

    Con respecto a tu pregunta, la KB está en la red y el Tomcat está en un Linux con Samba.
    ResponderEliminar
  4. Entonces seguramente la versión 8 del nmake tiene problemas para validar diferencias de fechas entre un filesystem windows y Linux
    El make file chequea si los archivos del repositorio de Servlets (que está en Linux) difiere en fecha, si es así, copia los mismos al repositorio nuevamente, cierra mucho con el issue que describiste.

    Si al nmake le indicas el parámetro -D retornará seguramente cual es la diferencia en fechas.
    Seguramente en la versión del nmake que funciona bien las fechas darán iguales.

    Excelente que exista un nmake que funcione bien con Linux, muy mal para Microsoft que con nuevas versiones "falle" haciendo ese método de verificación.
    ResponderEliminar

Suscribirse a: Comentarios de la entrada (Atom)