lunes, marzo 27, 2006

 

Optimizando el código

En este articulo intentare hacer que los programadores vean su código compilado en la cabeza según lo están escribiendo, al principio les puede parecer complicado pero después de algún tiempo haciéndolo no lo es en absoluto.
Para ello vamos a deducir como un compilador trata las secuencias if y como debemos de hacerlo correctamente para ganar velocidad.
Tenemos este código:
struct Elemento
{
void *dato;
};

Elemento *Mete( void *dato )
{
if( dato == NULL )
{
return NULL;
}
Elemento *nuevo = new Elemento;
if( nuevo == NULL )
{
return NULL;
}
nuevo->dato = dato;
return nuevo;
}
 
Esta función mete un dato dentro de una estructura Elemento, es una función sin sentido pero que nos vale para lo que queremos hacer.
Como vemos este más o menos es el código que harían la mayoría de los programadores por comodidad, exceptuando que muchos quitarían las llaves, yo las dejo ya que vale para explicar mejor a donde quiero llegar, si examinamos el código veremos que si el dato pasado a la función es null queremos que de un error y salga, después creamos el elemento y si este null saldrá dando un error, si todo sale bien dato se almacena dentro de la estructura y esta es devuelta para su manejo, ahora les muestro el código que seria correcto para ganar velocidad:
struct Elemento
{
void *dato;
};

Elemento *Mete( void *dato )
{
if( dato != NULL )
{
Elemento *nuevo = new Elemento;
If( nuevo != NULL )
{
nuevo->dato = dato;
return nuevo;
}
}
return NULL;
}
 
Como se ve la lógica del código es contraria totalmente a la anterior favoreciendo a los casos en que todo sea correcto, es decir, diferente a NULL, ¿y cual es el motivo de esto? el motivo es que todos los compiladores por lógica siempre que se entra dentro del if no se produce un salto, en cambio si el if no se cumple si que se produce, el motivo es que cuando el contenido de un if termina se tiene que seguir haciendo lo que va después, veamos lo que digo en un pseudo código:
comparar dato con NULL
es diferente?
{
… código dentro de las llaves
}
… código que va después
 
Como se ve si es diferente se hace el contenido de las llaves, pero sea o no diferente el código que va después siempre se hace, entonces llegamos a la conclusión de que el compilador producirá un salto para el caso contrario que pongamos nosotros, ya que si no el compilador realizara un salto al contenido de las llaves y después al final de estas otro salto a lo que va después de ellas, en conclusión, el compilador optimiza poniendo un salto a la comprobación contraria a la que ponemos nosotros, así solo produce saltos en el caso que no se cumpla lo que indicamos y siempre que se cumpla el código va secuencialmente, además de que al final de las llaves no se producirá un salto ya que al producirse solo cuando no se cumple el código esta justo debajo de las llaves.
Ahora examinando el primer código que puse veremos que estamos produciendo un salto siempre y en el segundo código se ve que solo se producirá el salto cuando las condiciones no se cumplan, esto también nos lleva a deducir en que siempre debemos de favorecer al código que se cumpla mas del 50% de las veces, es decir, en el segundo código vemos que lo normal es pasar un dato que no sea nulo y que la mayoría de las veces exista suficiente memoria como para crear una estructura Elemento, de esta manera no existirán saltos en el código, exceptuando claro esta el retorno de nuevo o null.
Mas beneficios de este sistema de programacion son codigos como este:
bool CrearMalla( int numVertices, int numIndices, char *fileShader )
{
VertexBuffer *vertices = new VertexBuffer( numVertices );
if( vertices != NULL )
{
IndexBuffer *indices = new IndexBuffer( numIndices );
if( indices != NULL )
{
Shader *shader = new Shader( fileShader );
if( shader != NULL )
{
return true;
}
delete indices;
}
delete vertices;
}
return false;
}
 
Viendo la logica nos damos cuenta que siempre que se haga todo correcto no se produciran saltos, si ocurre algun error se produce un solo salto y destruimos los objetos en el orden inverso de su creacion.

Comments:
Tienes unos errores en el segundo codigo. Tienes ¡ en vez de !
 
En efecto he visto que he puesto data en lugar de dato y que se ha puesto una letra I en vez de ! en las comprobaciones, me imagino que como lo escribo desde el Microft Word me lo habra cambiado, en principio da igual ya que lo que pretendo con el codigo es que muchos programadores lleguen a imaginarse su codigo compilado mientras programan.
Lo he cambiado, para que el codigo compile, gracias por el aviso.
 
Publicar un comentario



<< Home

This page is powered by Blogger. Isn't yours?