Post by TraumaHolas.
¿ Como se optimizan en c las sentencias if ? osea, el compilador supone
que la condición será verdadera la mayor parte de las veces, o supone que
será falsa.
El compilador, en la generalidad de los casos, no supondrá nada (a menos que
estemos ante una comparación de constantes, por ejemplo, porque entonces ya
no hay nada que verificar).
Post by TraumaEs que tengo un bloque if( ) cuya condición será falsa casi siempre ( solo
será verdadera la primera vez ) y, puesto que el bloque se ejecutará
muchas veces, me gustaría implementarlo lo más rápido posible.
A poco código que haya que ejecutar tras la condicional (comparado con la
propia evaluación), hacerlo en un orden u otro posiblemente no tenga
consecuencias significativas. Sin embargo, el principio general es obvio:
cuantas menos comparaciones tenga que hacer un programa, menos tardará en
ejecutarlas (de cajón, vamos).
Así, en el caso típico de una construcción if/then/else, el código
comprobará la primera expresión; si es cierta, ya ha acabado; si es falsa,
se irá al else. Por lo tanto, vemos que siempre será más rápido colocar
primero la condición que es más probable que sea cierta, ya que eso evitará
tener que comprobar la siguiente.
En tu caso, si sabes de antemano que la condición de búsqueda será cierta
sólo la primera vez, lo que puedes intentar es evitarte la comprobación
para los siguientes casos. Un ejemplo (muy tonto, pero que creo que
mostrará lo que quiero decir):
Si tenemos un análogo a...
for (i=0; i<10; i++){
(i<1) ? this() : that();
}
...donde se ve que la condición sólo será cierta la primera vez, pero será
evaluada todas ellas, se podría convertir en:
i=0;
while (i++<1) this();
while (i++<10) that();
...en general, "romper" el código en bloques para su ejecución estructurada
y minimizar las evaluaciones*1 (en principio, si puedes saber de antemano
cómo va a evolucionar tu "máquina de estado", deberías ser capaz de avanzar
sin necesidad de evaluar la situación en tiempo de ejecución).
Pero, volviendo al principio, no olvides que uno de los grandes males de la
programación es tratar de optimizar antes de tiempo. Salvo casos muy
específicos, es poco probable que tu evaluación requiera un tiempo
significativo, así que codifica primero de la forma más clara y lógica
posible. Sólo *después*, si tienes problemas de rendimiento, perfila la
aplicación para ver dónde están tus cuellos de botella (y no caigas en la
trampa de "buscar las llaves debajo de la farola": perfilar sólo la parte
que te sea más sencilla). Sólo *después* de haber perfilado la aplicación,
trata de optimizarla donde traiga más a cuenta: resiste la tentación de
optimizar donde te parezca más sencillo (sólo conseguirás un código más
enrevesado, con suerte, y un código incluso más lento, con mala suerte).
*1 En este caso trivial, hemos reducido las evaluaciones a la mitad.