It should work…

Y es que se ha perdido el romanticismo… xD

A día de hoy contamos con ordenadores chorrecientas veces más rápidos que hace pocos años y cuando se programa haces pruebas con sistemas de 3GHz, varios MB de cache y 2GB de RAM mínimo y todo tira para adelante. Bueno, todo tira hasta cierto punto, tus programas luego se van a estar ejecutando juntos con otras decenas de programas o simplemente se van a estar ejecutando constantemente y vas a perder un gran porcentaje de la capacidad de proceso de cómo lo podrías estar haciendo.

Bueno, y es normal, cosas de la comodidad, yo el primero. Ahora te quedas tranquilo con que funcione, en los 80 tenía que funcionar y caber en 64kB de RAM. No digo que se programe peor (seguramente sí xD) pero ya no nos fijamos en muchos detalles que antes eran totalmente necesarios (la de trucos que usaba la gente para poder aprovechar el 100% del hardware del Commodore64) y ahora desperdiciamos por todos lados y al final sí que pasa factura. La gente que programe sistemas embebidos lo tiene muy claro aunque casi se va a acabar el asunto también ahí porque ya los procesadores de los móviles/PDAs/cosas_pequeñas tirán mucho.

Me he encontrado con programas que están al 100% de CPU en idle, con programas que daban su salida en unos 12~15 minutos cuando otro para el mismo propósito lo hacía en aproximadamente 1 segundo (no daré nombres xD), programas en los que notas el ‘refresco’ de los elementos cuando lo usas cuando te sobra CPU para hacerlo bien, etc. Hay que intentar evitar marañas de bucles for anidados!

Al final todo pasa por conocer muy bien el lenguaje que usas, haber pasado horas y horas, pensar las cosas antes de hacerlas, incluso un poquito de sentido común, cosa que creo que es difícil de abstraer a veces cuando se programa.

Por ejemplo, en matlab es muy importante reservar el espacio para las variables antes y crear los vectores del tamaño que van a ser al final de las operaciones porque si aumentamos el tamaño de un vector[n], internamente lo que siempre hace es crear un nuevo vector[n+1] y copiar los datos del antiguo.

Hace unos meses me comentó un amigo que en el trabajo tenían un método númerico que disminuyó su tiempo de ejecución en más de un 20% (siendo su tiempo varias horas) al sustituir un resultado de una operación que siempre era el mismo por el valor guardado en una variable! Es de cajón pero hay que caer.

Y ahora vienen algunos ejemplos, por no meterme en un lenguaje tipo C en el que hay muchas posibilidades de hacer las cosas y hay que currarse más los ejemplo iré a algo más sencillo como es hacer scripts cerdos para administrar un máquinas o similares.

Un ejemplo sería un uso poco adecuado de las órdenes cat, grep, ls, awk y similares. Cuando manipulamos algo pequeño no pasa nada pero cuando se trata de varios ficheros logs y son decenas de MB pues la cosa empieza a tomar importancia.

Respecto a grep cuando una persona empieza y se plantea buscar una cadena lo primero que piensa es ‘muestro el archivo y luego saco las líneas coincidentes’:

# cat tinyproxy.log | grep remote
real    0m55.071s
user    0m24.477s
sys     0m0.727s

Luego descubres que en realidad lo puedes hacer ‘todo en uno’ y es bastantes más rápido:

# grep remote tinyproxy.log
real    0m36.024s
user    0m22.550s
sys     0m0.527s

Luego, sin querer, entras en el man y te das cuenta de que existen varios tipos: grep, egrep (similar pero no idéntico a grep -E ) y  fgrep (idéntico a grep -F). Así que pruebas:

# egrep remote tinyproxy.log
real    0m55.122s
user    0m25.029s
sys     0m0.659s

Joder, vuelve a ser lento a pesar de no hacer un cat. ¿Por qué? Porque es una función más compleja.

• grep: soporta expresiones regulares básicas.
• fgrep: no soporta expresiones regulares => el más rápido.
• egrep: soporta expresiones regulares avanzadas => el más lento.

Para los curiosos, el nombre grep viene de g/re/p y significa lo que hace tal cual, buscar una expresión regular y hacer print de las coincidencias. En realidad a una escala grande ni siquiera deberíamos usar grep sino sed que es más rápido.

Lo mucha gente desconoce es que hay otra manera de evitar el cat de antes y ganar tiempo, y es que en realidad las concatenaciones siempre están ahí… así que lo podríamos hacer del siguiente modo:

# <tinyproxy.log grep remote
real    0m43.931s
user    0m22.338s
sys     0m0.578s

Del mismo modo estos conceptos se puede usar en otras órdenes

# cat tinyproxy.log | wc -l
104265

real    0m0.088s
user    0m0.021s
sys     0m0.053s

# wc -l tinyproxy.log
104265 tinyproxy.log

real    0m0.021s
user    0m0.013s
sys     0m0.006s

Y del mismo modo:

# cat tinyproxy.log | tail -n 200
real    0m0.121s
user    0m0.026s
sys     0m0.056s

# tail -n 200 tinyproxy.log
real    0m0.010s
user    0m0.000s
sys     0m0.003s

Cambiando de tercio también solemos usar echo más veces de las que toca. Por ejemplo si tenemos :

var="valor_o_resultado_de_una_evaluacion"
command -options `echo $var`

en la mayoría de los casos podremos sustituirlo por:

var="valor_o_resultado_de_una_evaluacion"
command -options $var

Y así mil chorradas. Por cierto, el que sólo se conozca la opción de awk para coger columnas le recomiendo que se mire manules que termina siendo muy útil.

Creo que este post lleva más de 6 meses en drafts y no he añadido nada (de hecho tampoco tengo ganas), así que aunque es un tema que da mucho de sí ha quedado bastante descafeinado técnicamente, pero ajo y agua!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descodificar tonos DTMF usando Matlab
• Port-Knocking y Crypt-Port-Knocking
• Dejar bonito un server SSH – Parte 1