sábado, septiembre 29, 2007

Cosas que un desarrollador debe saber

Es habitual que cuando uno aprende a programar (ya sea educación formal o autodidacta) en lo que se pone énfasis es en el lenguaje, es decir, la controles de flujo, las iteraciones, etc. Luego cuando uno domina eso y comienza a desarrollar programas más grandes y comienzan a aparecer errores difíciles de encontrar lo que uno instintivamente hace es comenzar a poner print's (printf(), writeln, etc.) de la variables de interés, luego cuando son problemas más complejos y que hacen uso intensivo de cpu y uno busca mejorar el rendimiento (algoritmos golosos, dividir para conquistar, programación dinámica, etc.) nuevamente se echa mano a los print's y más o menos calcula en que parte se tarda más en pasar el flujo (los más avezados imprimen la hora y los aún más avezados hacen un difftime), PERO ¿por que mierda, los profesores, no nos dicen que existen herramientas para hacer lo mismo?. Yo en la universidad nunca le escuché a hablar a un profe del profiling, de usar un debugger, etc.

Pues bueno aquí va un pequeño esbozo de en que momento usar que cosas:

Si tu programa tiene errores y hace cálculos absurdos, lo que debes utilizar es un debugger, con eso puedes hacer lo mismo que con los print's (pero sin contaminar el código con print's) y muchas otras cosas más, como por ejemplo cuando tu aplicación se va de sgfault puedes imprimir el stack, puedes ver los valores que habian en las variables antes del segfault, puedes poner breakpoints (un breakpoint es un punto del código donde se queda en pausa el código y puedes comenzar a ejecutar step-by-step o hasta el siguiente break, etc.). Traten de hace eso con solamente print's XD. La primera vez que usen el debugger les quitará harto tiempo en aprender las cosas básicas (en especial si usas gdb como los machitos, aka sin-gui :P), pero a largo plazo el beneficio es enorme. (si usas python te puede interesar ver Introducing the pydb Debugger)

Si tu programa ha crecido y comenzó a ponerse un devorador de memoría y/o cpu, pues entonces haz profiling de tu aplicación :) y el profiling es aplicable también a la red (en caso de que tu software haga uso de ella), los datos obtenidos los podrás graficar y análizar los casos en que tu aplicación se pone lenta etc. (si les interesa el tema les recomiendo el video Linux.conf.au Profiling Desktop Apps)

Eso fue el consejo del día de hoy :P

PD: se dice que el profiling en linux es algo limitado debido a la falta de hooks en el kernel, pero eso no me consta empíricamente :P
PD2: más información en wikipedia: Performance analysis y Debugging

2 comentarios:

Trumbulianos IV 2007 dijo...

Gracias amigo felipe por el apoyo :). Genial tu blog también, interesante lo de linux.
Un consejo: trata de personalizar un poco tu blog, para hacerlo mas atractivo, pero el contenido esta re bien.
Saludos del Equipo Arquiware.

Anónimo dijo...

ajejejejjaja nunca enseñaron a ocupar el gdb por la #### a puras violaciones de segmento y printf cuec. en fin ya paso.