Barrapunto

Muchisimas gracias por llamar excelente introducción a este (inacabado) mini-tutorial con faltas horrográficas :-P . (mayormente, por un tema de migración).

También es verdad que en castellano hay poco más sobre DTrace, después de todo, por eso me dió por empezarlo. (Aunque si no le teneis miedo al inglés, mirar la (esta sí :-P) excelente guia oficial [sun.com])

De todas formas, parece ser que no interesa mucho casi nada relacionado con DTrace en barrapunto, porque despues de hora y media de su publicación un sabado, este es el primer comentario en la noticia (ni siquiera entradas de trolls) :-S

Despues de un año utilizandolo en el trabajo, debo decir que es una herramienta extremadamente util y efectiva. Hemos desarrollado ya cuatro proyectos tremendos, entre setenta personas, y sin este software hubiera sido muchisimo mas dificil terminar con los malditos bugs. La verdad, os recomiendo probarlo. ¿Soy la unica a la que le parece que Sun se lo esta currando mucho desde hace unos años?

Pues si os interesan estas cosas, decir que para nuestro amado Linux también tenemos "cosillas": SystemTap [sourceware.org] Sin menos preciar a SunOS, que me quito el sombrero.

--
kernel-labs.org [kernel-labs.org]

Este párrafo me ha parecido muy interesante (traducción abajo):

System performance problems are typically introduced at the highest layers of abstraction, but they are often first encountered and attributed at the lowest layers of abstraction. It is because of this paradox that we have adopted the myth that the path to performance lies nearly exclusively with faster hardware: faster CPUs, more networking bandwidth, etc. When this fails, we have taught ourselves to move to the next layer of the stack: to demand faster operating systems, faster databases, and better compilers. Improving these components undoubtedly improves performance, but (to use a perhaps insensitive metaphor) it amounts to hunting vermin: Depending on the relatively small iterative improvements at the lowest layers of the stack amounts to trying to feed a family on the likes of squirrel and skunk. If we can move up the stack—if we can find the underlying performance problems instead of merely addressing their symptoms—we can unlock much more substantial performance gains. This is bigger game to be sure; by focusing on performance problems higher in the stack, we can transition from hunting vermin to hunting cow—big, slow, stupid, tasty cow.

Los problemas del rendimiento del sistema se introducen típicamente en las capas más altas de abstracción, pero son a menudo encontrados y atribuídos a las capas más bajas de abstracción. Es a causa de esta paradoja que hemos adoptado el mito de que el camino hacia el rendimiento se haya exclusivamente con hardware más rapido: CPUs más rápidas, más ancho de banda de red, etc. Cuando esto falla, hemos aprendido a movernos a la siguiente capa de la pila: pedir sistemas operativos más rápidos, bases de datos más rápidas y mejores compiladores. Mejorar estos componentes sin duda mejora el rendimiento, pero (usando quizás una insensible metáfora) equivale a cazar bichos: depender de las relativamente pequeñas mejoras iterativas en las capas más bajas de la pila equivale a intentar alimentar a una familia del tipo de la ardilla y la mofeta. Si podemos subir en la pila—si podemos encontrar los problemas subyacentes en lugar de simplemente hacer caso de los síntomas—podremos desbloquear muchas más ganancias sustanciales de rendimiento. Este es ciertamente un juego más grande; concentrándonos en los problemas de rendimiento más arriba en la pila, podemos pasar de cazar bichos a cazar vacas—grandes, lentas, estúpidas y sabrosas vacas.

No es por nada, pero muchas veces cuando haces una crítica de rendimiento sobre algún programa siempre te saltan diciendo que la solución es más hardware, cuando como pone aquí, el problema está a menudo en las capas más altas del sistema (sólo que cuesta mucho darse cuenta de las causas reales). Me viene a la memoria por ejemplo esa página que hay por ahí de "consejos para mejorar el rendimiento en KDE [kde.org]" donde aconsejan comprar mejor hardware, o muchas otras páginas o foros de proyectos.
En otra parte del artículo se dice que lógicamente el código en las capas más altas genera muchísimo código en las capas más bajas, y que hay que tener mucho cuidado con ello.
Espero que algún día con el uso de estas herramientas encontremos una nueva forma de observar el software y podamos ya de una maldita vez localizar la mayoría de problemas de rendimiento que tenemos en los escritorios más populares de Linux (y en otros programas). Basta de hipocresía: tenemos problemas de rendimiento y hay que solucionarlos.