Resumen: Code Complete: A Practical Handbook of

Software Construction, Microsoft Press

Leandro León nombre
Facultad: Ingenría de Sistemas Facultad: Ingenría de Sistemas
Universidad Poltécnica Salesiana Universidad Poltécnica Salesiana
Cuenca - Ecuador Cuenca - Ecuador
cleonc2@est.ups.edu.ec correo@est.ups.edu.ec

nombre
Facultad: Ingenría de Sistemas nombre
Universidad Poltécnica Salesiana Facultad: Ingenría de Sistemas
Cuenca - Ecuador Universidad Poltécnica Salesiana
correo@est.ups.edu.ec Cuenca - Ecuador
correo @est.ups.edu.ec

Abstract. - If you need to optimize a robust program, several
points must be considered, such as: why? And for what? The
optimization of the program and it is good to say that there are
options how to do it. One of them is the Tuning code, which is
reviewed in section Code-Tuning Strategies. It should be emphasized
that within this, the points of view should also be analyzed, if time or
performance is to be optimized. A comparison is made between
resources in different tasks without and with optimization, resulting
in time or performance depending on the case. It is expected that
after reviewing this section the reader has a clearer picture and skills
to be able to carry out the tuning code task.
Index Terms – Ajuste de Código, .
I. INTRODUCTION
Si se necesitase optimizar un programa robusto, se debe
tener en cuenta varios puntos como, por ejemplo: ¿por qué? Y
¿para qué? La optimización del programa y es bueno decir que
hay opciones de cómo hacerlo. Uno de ellos el ajuste de Código
el que se revisa en la sección Estrategia de Ajuste de Código.
Cabe recalcar que dentro de este también se debe analizar los
puntos de vista sería si se quiere optimizar el tiempo o el
rendimiento. Se hace una comparación entre recursos en
diferentes tareas sin y con la optimización, dando como
resultado un tiempo o rendimiento dependiendo del caso. Se
espera que después de revisar esta sección el lector tenga una
imagen más clara y aptitudes para poder llevar a cabo la tarea
de ajuste código.
II. ESTRATEGIA DE AJUSTE DE CÓDIGO
A. Rendimiento
7 Entonces ¿Cuál es el atractivo del ajuste de código?, pues su
El ajuste de Código es una forma de mejorar el rendimiento
de un programa. Pero hay varias formas de cumplir este
objetivo y en los cuales varía también el tiempo e influye el
daño al código.
Características de calidad y rendimiento
Pensamos que mientras más bien hecho esté nuestro código,
más le gustará al cliente, pero al cliente o usuario le importa
más lo tangible del programa que en la calidad del código. Un
cliente se interesa en el rendimiento bruto sólo si esto afecta a
su trabajo.
El rendimiento está relacionado con la velocidad del código.
Así que hay que tener cuidado de no sacrificar otras
características para acelerar el código, ya que podría afectar a
su rendimiento en vez de ayudar.
Rendimiento y ajuste de código
Una vez elegida la eficiencia como prioridad, ya sea en la
velocidad o en tamaño, también hay que considerar varias
opciones antes de elegir mejorar cualquiera de los dos puntos
mencionados.
 Requerimiento de programa
o
 Diseño de programa
 Diseño de clases y rutina
 Interacciones del sistema operativo
 Compilación de código
 Hardware
 Ajuste de código
B. Introducción al ajuste de código
La arquitectura del programa, la selección de algoritmos y
el diseño de clases producen mejoras más significativas.
Comprar nuevo hardware o un mejor compilador es más
económico.
atractivo está en que parece desafiar las leyes de la naturaleza,
por ejemplo, tomar una rutina que se ejecuta en 20
microsegundos y ajustar a que se ejecute ahora en 2
microsegundos. Y se podría decir que otro atractivo es, la
oportunidad para convertirse en un mejor programador
haciendo estos ajustes.
El problema con el ajuste del código es que el código eficiente optimizando código que no necesita ser
no es necesariamente un código "mejor". optimizado.
El principio de Pareto Un programa rápido es tan importante como uno
También conocida como la regla 80/20, establece que puede correcto: ¡falso! Para una determinada clase de
obtener el 80% del resultado con el 20% del esfuerzo. proyectos, la velocidad o el tamaño es una
Barry Boehm informa que el 20% de las rutinas de un programa preocupación importante.
consumen el 80% de ejecución. Cuando sintonizar
Knuth encontró que menos del cuatro por ciento de un No se debe optimizar hasta que se sabe que lo necesita
programa generalmente representa más del 50 por ciento de su hacer. Un ajuste importante puede sacar a la luz que
tiempo de ejecución. Knuth utilizó un perfilador de recuento de menos del 1% del código representa el 90% de tiempo
líneas para descubrir esta sorprendente relación. Knuth hizo un de ejecución.
perfil de su programa de conteo de líneas y descubrió que estaba Optimizaciones del compilador
gastando la mitad de su tiempo de ejecución en dos bucles. Cada compilador tiene diferentes fortalezas y
Cambió algunas líneas de código y duplicó la velocidad del debilidades, y algunas serán más adecuadas para su
perfilador en menos de una hora. programa que otros. Aquí están los resultados de
Cuentos viejos de esposas. algunas pruebas para verificar cuánto aceleró un
Algunas afirmaciones sobre el ajuste de código son optimizador una rutina de clasificación de inserción:
falsas, incluidas las siguientes interpretaciones. Lengua Tiempo Tiempo Tiempo Proporció
La reducción de las líneas de código en un lenguaje je sin optimiza ahorra n de
de alto nivel mejora la velocidad o el tamaño de optimizar do el do rendimien
código de máquina resultante: ¡falso! el compilad to
Considere el siguiente código que inicializa una matriz compilad or
de 10 elementos: or
for i = 1 to 10 C++ 2.21 1.05 52% 2:1
a[ i ] = i compile
end for r1
Estas líneas son más rápidas o más lentas que las C++ 2.78 1.15 59% 2.5:1
siguientes 10 líneas que hacen lo mismo. compile
a[ 1 ] = 1
a[ 2 ] = 2
r2
a[ 3 ] = 3 Visual 1.55 1.55 0% 1:1
a[ 4 ] = 4 Basic
a[ 5 ] = 5 Java 2.77 2.77 0% 1:1
a[ 6 ] = 6 VM 1
a[ 7 ] = 7 Java 1.39 1.98 <1% 1:1
a[ 8 ] = 8 VM 2
a[ 9 ] = 9
a[ 10 ] = 10
Se diría que el primer código es más rápido. Pero las C. Tipo s de grasa y melaza
pruebas en Microsoft Visual Basic y Java han Encontrar partes de programa que son lentos y robustos y,
demostrado que el segundo fragmento es al menos un cambiarlos para que sean tan rápidos como un rayo y tan
60% más rápido que el primero. delgados que pueden esconderse en las grietas entre los otros
Ciertas operaciones son probablemente más rápidas bytes en la RAM.
o más pequeñas que otras, ¡falso! Fuentes comunes de ineficiencia
Siempre debe medir el rendimiento para saber si sus Aquí hay varias fuentes comunes de ineficiencia:
cambios ayudaron o perjudicaron su programa. Las Operaciones input/output Si se trabaja con datos
reglas del juego cambian cada vez que cambias externos, es preferible guardarlos en memoria y no
idiomas, compiladores o las versiones de estos, tener conectado algún dispositivo externo con estos
también cantidad de memoria y el procesador. datos.
Lo que era verdad en una máquina con un conjunto de Aquí, una comparación entre el código que accede a
herramientas puede ser fácilmente falso en otra un dispositivo exterior y uno que accede a un
máquina con un conjunto diferente de herramientas. directorio.
Debe optimizar a medida que avanza, ¡falso! Los
programadores ignoran las optimizaciones globales
importantes porque están demasiado ocupados con las Lengua Tiempo Tiempo Tiempo Proporció
micro optimizaciones. je Dispositi Director ahorrad n de
Cuatro 4% del código representa el 50% del vo io o rendimien
tiempo de ejecución, esto quiere decir que los exterior to
programadores pasaran el 96% de su tiempo
 C++ 6.04 0.000 100% n/a
C# 12.8 0.0.10 100% 1000:1
Según estos datos, el acceso en memoria es del orden
de 1000 veces más rápido que acceder a datos en un
archivo externo.
Paginación Una operación que hace que el sistema
operativo intercambie páginas de memoria es mucho
más lento que una operación que funciona en una sola
página de memoria.
Ejemplo de Java de un bucle de
inicialización que causa muchos errores de página
for(column=0;column<MAX_COLUMNS;column++ ) {
for (row= 0; row < MAX_ROWS; row++ ) {
table[row][column]=BlankTableElement();
} Debe seguir los siguientes pasos mientras considera si la
} optimización del código puede ayudar a mejorar el rendimiento
¿Cuál es el problema? El problema es que cada
almacenamiento tiene 400 bytes de longitud, cada vez
que el programa accede a una fila diferente, el sistema
operativo tendrá para cambiar de página de memoria.
El programador reestructuró el bucle de esta manera:
Ejemplo de Java de un bucle de inicialización
que causa muchos errores de página
for ( row = 0; row < MAX_ROWS; row++ ) {
for(column=0;column<MAX_COLUMNS;
column ++ ) {
table[row][column]=BlankTableElement();
} d. Ajuste el cuello de botella identificado en el paso
} (c).
Este código todavía causa un error de página cada vez
que cambia de fila, pero solo cambia de fila
MAX_ROWS veces en lugar de MAX_ROWS *
MAX_COLUMNS veces.
Lenguajes de interpretación Los idiomas
interpretados tienden a exigir un rendimiento
significativo sanciones porque deben procesar cada
instrucción de lenguaje de programación antes
Creación y ejecución de código de máquina.
Errores Una fuente final de problemas de rendimiento
son los errores en el código.
Costos de desempeño relativo de operaciones comunes
Aunque no puede contar con que algunas operaciones sean más
caras que otras sin medirlas, ciertas operaciones tienden a ser
más caras.
La mayoría de las operaciones comunes tienen el mismo precio:
llamadas de rutina, asignaciones, la aritmética de enteros y la
aritmética de coma flotante son aproximadamente iguales.
D. Medición
Debido a que pequeñas partes de un programa
generalmente consumen una parte desproporcionada del tiempo
de ejecución, mida su código para encontrar los puntos
calientes. Una vez que haya encontrado los puntos calientes y
optimizados, vuelva a medir el código para evaluar cuánto lo ha
mejorado.
Las mediciones deben ser precisas
Las herramientas de creación de perfiles son útiles, o puede usar
el reloj y las rutinas de su sistema que registran tiempos
transcurridos para operaciones informáticas.
Asegúrese de medir solo el tiempo de ejecución del código que
está ajustando.
E. Iteración
Una vez que haya identificado un cuello de botella en el
rendimiento, se sorprenderá de cuánto puede mejorar el
rendimiento mediante el ajuste de código. Si la mayoría de las
optimizaciones son pequeñas individualmente, en grupo
podrían ser significativas.
F. Resumen del enfoque para el ajuste de código
de un programa:
1. Desarrolle el software utilizando un código bien
diseñado que sea fácil de entender y modificar.
2. Si el rendimiento es pobre
a. Guarde una versión funcional del código para
poder volver al "último buen estado conocido ".
b. Mida el sistema para encontrar puntos calientes.
c. Determine si el rendimiento débil proviene de un
diseño inadecuado, tipos de datos o algoritmos y si el
ajuste de código es apropiado.
e. Mida cada mejora de una en una.
f. Si una mejora no mejora el código, vuelva al
código guardado en paso (a).
3. Repita desde el paso 2.
III. UNITS
REFERENCES
[1] M. King, B. Zhu, and S. Tang, “Optimal path planning,” Mobile Robots,
vol. 8, no. 2, pp. 520-531, March 2001.
[2] H. Simpson, Dumb Robots, 3rd ed., Springfield: UOS Press, 2004, pp.6-9.
[3] M. King and B. Zhu, “Gaming strategies,” in Path Planning to the West,
vol. II, S. Tang and M. King, Eds. Xian: Jiaoda Press, 1998, pp. 158-176.
[4] B. Simpson, et al, “Title of paper goes here if known,” unpublished.
[5] J.-G. Lu, “Title of paper with only the first word capitalized,” J. Name
Stand. Abbrev., in press.
[6] Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy
studies on magneto-optical media and plastic substrate interface,” IEEE
Translated J. Magn. Japan, vol. 2, pp. 740-741, August 1987 [Digest 9th
Annual Conf. Magnetics Japan, p. 301, 1982].
[7] M. Young, The Technical Writer’s Handbook, Mill Valley, CA: University
Science, 1989.