Lo que proponía Juanjo (de probarlo con el g++ optimizando a tope) me ha parecido buena idea, así que he hecho unas cuantas pruebas en C++.

Los resultados han sido interesantes

Para mi grata sorpresa, el g++ ha optimizado muy bien la función strlen. Sin embargo, no es capaz de optimizar “cualquier” función que tenga sus mismas características.

En el archivo test-strlen.cpp he realizado varias pruebas (más abajo están los fuentes descargables en un .tgz).

La primera prueba ha sido realizar un bucle con strlen, tal cual el código de PHP, y otro donde el strlen está fuera del bucle.

 // strlen dentro del bucle
 for (j = 0; j <= strlen (str); j++) {
    copy [j] = str[j];
 }
 
 /* [...] */
 
 // strlen fuera del bucle
 len = strlen (str);
 for (j = 0; j <= len; j++) {
    copy [j] = str[j];
 }

Ha resultado que el g++ ha optimizado muy bien el primer bucle, hasta el punto que ambos probablemente ejecuten el mismo código, no se aprecia diferencia.

Una vez hecho esto, me he dicho, voy a fastidiar un poco al compilador, así que he añadido una linea, que básicamente modifica str, que es la cadena que se le pasa al strlen, para que el compilador tenga que evaluar siempre el bucle:

 // strlen dentro del bucle, modificando str
 for (j = 0; j <= strlen (str); j++) {
    copy [j] = str[j];
    if (j == 1) str[j] = str[j-1];
 }

El caso es que ha funcionado, básicamente el compilador no lo ha podido optimizar, no obstante esto no me vale para ejemplificar lo que decía en el artículo anterior, porque el compilador ha hecho lo que tenía que hacer, y la variable ha sido modificada dentro.

He aquí los resultados de test-strlen:

Making the common mistake(not optimizable): 9.20
Making the common mistake(optimizable by the compiler): 0.00
Avoiding the common mistake: 0.00

Total, que he creado otro archivo de ejemplo, el test-custom-strlen.cpp cuyo objetivo es implementar una función equivalente a strlen y ver si el compilador es igual de inteligente.

Básicamente, en este archivo he creado 5 funciones, vease: custom_strlen, custom_strlen_const, custom_strlen_const2, strlen_wrap, strlen_wrap_const

/** this is a custom strlen function */
size_t custom_strlen (char *str)
{
  char *ptr = str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
  return (size_t)(ptr - str);
}
 
/** this is same as above, but telling the compiler we are not touching str*/
size_t custom_strlen_const (const char *str)
{
  const char *ptr = str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
  return (size_t)(ptr - str);
}
 
/** this strlen updates input string, no matter that is const */
size_t custom_strlen_const2 (const char *str)
{
  char *ptr = (char*)str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
 
  ((char*)str)[0] = 'a'; // update string
 
  return (size_t)(ptr - str);
}
 
/** this is a wrapper over strlen function */
size_t strlen_wrap (char *str) {
  return strlen (str);
}
 
/** this is a wrapper over strlen function with constant input */
size_t strlen_wrap_const (const char *str) {
  return strlen (str);
}

Y los resultados ha sido los siguientes:

using custom_strlen: 3.90
using custom_strlen_const: 4.05
using custom_strlen_const2: 4.04
using strlen_wrap: 0.00
using strlen_wrap_const: 0.00

Vamos, que el compilador, con -O3, no ha sido capaz de optimizar ninguna de mis funciones. Y el caso es que la función custom_strlen_const era candidata para ser optimizada igual que el strlen (función con un parámetro constante, internamente usa const para todo y no cambia el valor de nada).

Total, que sigo manteniendo la misma opinión que en el artículo anterior: si una función se va a evaluar siempre a lo mismo, mejor que esté fuera del bucle, porque no se sabe si el compilador o intérprete va a ser capaz de optimizarla o no.

También me gustaría decir que por lo general este tipo de cosas, normalmente, tampoco va a suponer ningún cuello de botella en ninguna aplicación, ni va a suponer tiempos abismales de ejecución, por lo que no es preciso prestarle mucha importancia; ahora bien, son pequeños detalles, que se van sumando y sumando, y oye, quizá no reduzcan los tiempos un 30%, pero un 5%…

Aquí teneis el archivo comprimido con los códigos fuentes de ejemplo. (descomprimir, ejecutar make y listo)

¿Alguien ve algo raro en el siguiente código?

<?php
for ($i = 0; $i < strlen ($string); $i++) {
    // whatever this loop does
}

A priori ¿Parece que todo está bien, no? Si te lo parece es que no eres consciente aún.

Es bien sabido que las condiciones de los bucles se evaluan tantas veces como iteraciones tiene el bucle, con esto no estoy descubriendo nada a nadie, sin embargo, si se mete un strlen para medir la longitud de la cadena en un bucle que se ejecuta tantas veces como caracteres hay, acabamos de elevar al cuadrado el tiempo de ejecución.

Tanto en C como en PHP, la función strlen necesita recorrer toda la cadena hasta encontrar el ‘\0′ para determinar su longitud, así pues, si la longitud es 20, strlen necesitará 20 iteraciones para determinar que la longitud es 20. El problema es que el bucle que estamos haciendo también tiene 20 iteraciones, y en cada iteración se ejecuta strlen, que consume otras 20 iteraciones (claro que en PHP esas 20 iteraciones se ejecutan en código máquina, y no en el interprete), por lo que tendríamos que el coste de ese bucle para una cadena de 20 caracteres es de 20*(20 + lo que hay dentro del bucle) = 400 + 20*lo que hay dentro del bucle.

El siguiente script (error común con los bucles) muestra un ejemplo de esto en PHP, donde dentro del bucle no se hace nada, y se puede observar como un bucle es mucho más lento que el otro.

Los resultados tras ejecutarlo en mi ordenador han sido:

strlen($sentence) =  12608 bytes
Making the common mistake: 3.02566313744 seconds
Fixing the common mistake: 0.958508968353 seconds

Creo que se puede apreciar claramente la diferencia

Finalmente, aunque he usado PHP para ilustrar el error, y concretamente strlen, si nos olvidamos de strlen y de PHP, esto es aplicable a otros muchos lenguages C/C++/Java/Pascal/PHP/Python/Perl/Ruby y un largo etcetera; y pasa en todos los lenguajes porque todos los lenguajes usan el mismo concepto, la condicion de salida del bucle se evalua en cada iteración. Quizás no ocurra cuando se utilizan cadenas, porque guardan la longitud en una variable, pero puede que pase al mirar la longitud de listas enlazadas, etc…

Conclusión: si en el bucle estás llamando a una función que siempre te va a devolver lo mismo, mejor guardalo en una variable y usa esa variable dentro del bucle, te ahorrará sorpresas

Enlaces interesantes:

• Back to basics, un excelente artículo de Joel (disponible en Español) donde reflexiona sobre algunas cosas directamente relacionadas con esto.