miércoles, 8 de abril de 2009

Incremento de un 100% de rendimiento de java.util.Logger (o los detalles sí importan)

Delicioso post de Jeremy Manson, que lleva tiempo teniéndnos "abandonaditos"...:

http://jeremymanson.blogspot.com/2009/04/faster-logging-with-faster-logger.html

A raíz de la necesidad de un cliente, que quería nada menos que un throughput de 2 MB por segundo en la escritura de logs (!), se han hemos una serie de optimizaciones en Logger.log para alcanzarlo, y se ha alcanzado...

Los cambios ya están disponibles en el último build de OpenJDK, y más detalles en http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6797480.

El código de Jeremy es precioso en si mismo (lo siento, seguramente un no-programador no puede entender el adjetivo precioso aplicado a esto). Toda una clase de sincronización y volatilidad. Y es el mejor ejemplo de que el mejor "Escape analysis" sigue haciéndolo el ingeniero...

Pero, y por mucho que él le quite culpas al desarrollador original de esa clase (incorporada en JDK 1.4)... joder ¿eso siempre ha estado ahí? ¿los procesos de entrega de Sun Microsystems no incluyen búsqueda de puntos calientes o locks adquiridos en cada thread?

Lo cierto es que me ha dejado un sabor de boca muy muy agridulce...

1 comentario:

Martín dijo...

Bueno, lo que dice el hombre tiene mucho sentido claro. El desarrollador original poco más podía hacer porque el comportamiento de volatile en el jdk 1.4 se podría decir que era exactamente eso, "volatil".

Y una vez hecho, me imagino que el proceso de Sun es el mismo que el de otras muchas: optimización bajo chequera. Tu pones la pasta, yo optimizo.

Lo bueno en este caso es que esto no se quedará en un parche privado para el cliente, que también es una práctica común