[IRC-DEV] Vuelvo a mandar la prueba de rendimiento

[Jesus Cea Avion]

Esa funcion se puede optimizar mucho, y de formas mejores. Por ejemplo,
las cadenas se normalizan varias veces: cuando se calcula el hash y
cuando se realiza la búsqueda en un "bucket". Limitar esas conversiones
gana más que lo que tú propones.

De todas formas me interesaría más coger un ircd real y hacerle un
"profiling" para ver hasta qué punto compensa optimizar esas rutinas. Si
aceleras una función el 50%, pero esa función es el responsable de
únicamente el 1% de la CPU consumida, no resulta ni rentable ni
inteligente. Es tiempo desperdiciado y mal invertido.

>  - Eliminar esos mallocs, aunque tan solo se haga 1 malloc en el ircd,

El problema no es el malloc, que se ejecuta un puñado de veces en toda
la vida del ircd, sino el strlen asociado. Y esa función es un problema
porque los GCC modernos no hacen "inlining" de él. Simplemente cambiando
el strlen por un bucle "manual" sería un gran avance con los GCC
actuales.

Otra posibilidad es olvidar el tema de búferes dinámicos y simplemente
tener un buffer estático, que es lo que yo he hecho en la comparativa.

> - Se elimina el strlen, que ya implica llamar a la función que está en
> la lib, recorrer toda la cadena, y devolver un valor.

Éste sí es un problema.

> - Se elimina el strcpy, que implica lo mismo, pero añadiendo el
> trabajo de copia de los caracteres de una cadena a otra.

Eso se puede eliminar sin problemas, como he hecho en mi comparativa.

> - Se elimina el toLower, que evita volver a recorrer toda la cadena.

Veamos... con mi sistema se llama a "tolower" una vez por cada byte de
la cadena a buscar.

Con tu sistema se llama a "tolower" DOS veces por cada byte de la cadena
a buscar y MULTIPLICADO cada registro en el bucket. Claramente un
problema si un bucket tiene más de un par de entradas, lo que es normal.
Es más, es inevitable si el número de buckets es menor que el número de
registros.

Si en vez de hacer tus pruebas con 10 registros, tuvieses 100 (en tu
código de pruebas), lo notarías.

> - Además, la función sería inline, por lo que evita la llamada a esta
> cada vez que se solicita un registro, que es algo constante en el
> ircd.

Me parece bien.

Creo que las cosas comentadas con "microoptimizaciones". Hay bastantes
lugares en el ircd donde invertir una hora de tiempo supone un mayor
beneficio que lo que comentas. Yo te pediría que invirtieses esa hora en
donde resulte más rentable.

Por ejemplo, el tema de la abstracción de "sockets" de esta mañana. O la
evaluación de "baneos" o "g-lines". Otra cosa que convendría analizar es
el uso "optimizado" de las cachés de las CPUs actuales, algo que el IRCD
actual ni siquiera entra a valorar, y la diferencia de rendimiento puede
ser más que apreciable.

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz