4 bits blog

Empecemos con algo lúdico-festivo:

Juanito fue contratado para pintar una carretera. El primer día pintó 100 km, el segundo 70 y el tercero 30. Su jefe, preocupado por esta alarmante bajada en su rendimiento le preguntó qué le pasaba, a lo que Juanito le contestó: “Es que el cubo de pintura cada vez me queda más lejos”

El rendimiento de un programa es, a grosso modo, lo que tarda en realizar su cometido. Es, de todas las métricas de calidad, una de las más difíciles de evaluar para mí. No solemos disponer de ejemplos lo suficientemente grandes, en ocasiones el problema aparece en una librería de terceros o, simplemente, se escapa de nuestro control (hasta que aparece). Lo que suele ser común en todos los casos es el mal uso de los tipos String (o similar), y es que en todos los lenguajes que conozco el tratamiento de los String es una mierda (bueno, en realidad suele estar entre una puta mierda y una putísima mierda).

Os expongo como ejemplo lo que me ha pasado con un proyecto recientemente. Consistía en generar unos ficherucos y enviarlos a un servidor vía HTTP. No problem. Los ficheros con los que probamos funcionaban a las mil maravillas y el proyecto pasó a pilotaje dividido en 2 partes: la generación y el envío. Cuando quisieron hacer una prueba enviando datos de un mes (en lugar de un día), aquello explotó. Revisando toda la parte de generación solventamos el problema y pasó de tardar 8 horas a 15 segundos, ¡¡cambiando sólo 3 líneas de código!!. La cosa siguió funcionando hasta la semana pasada, en que empezaron a fallar ficheros de 75 y 40 megas respectivamente, ahora en la parte de envío (solventado el jueves :)).

Éste es un tema para hablar largo y tendido, porque ejemplos hay miles y creo que todos los que hayamos programado habremos sufrido estas pérdidas, en principio inexplicables. Y, además, está relacionado con algo de lo que hablaré dentro de poco (espero): trampear los límites.