STL Performance

Atentos a std::move :)

http://blogs.msdn.com/b/vcblog/archive/2009/06/23/stl-performance.aspx

El post habla por si solo. Simplemente tenía curiosidad por saber que había por Google sobre las STL, ya que a mi parecer aunque son Thread Safe, son lentas como contenedores. Depende de con que lo compares son extremadamente rápidas claro. Pero no hay nada como una clase Array con las funciones necesarias. Se nota el aumento de rendimiento pero claro, las STL son diseñadas para un propósito general. La duda me asaltó cuando vi en una issue de la librería de física Bullet, un parche subido con contenedores STL y alguien dijo que el uso de las STL en Bullet era totalmente inaceptable :D y claro… si buscas optimización… tiene toda la razón.

No obstante no creo que las STL sean una mala librería, para nada, pero en el mundo del programador de C/C++ nos gusta bastante optimizarlo todo, yo al menos soy bastante friki con estos temas, no como desearía pero lo soy. Con decir que me he llevado 10 años con un PC AMD Athlon XP 1500+ 640MB de memoria y programé ahí mi implementación del Deferred Rendering… xD y siempre ejecutaba todo en DEBUG, si iba mal en debug tocaba iteración de profiling y optimización.

Me encanta C/C++, si bien es cierto que como siempre digo tienes toda la cuerda para hacer lo que quieras, absolutamente todo, pero también tienes la misma cuerda para ahorcarte.

(81 Posts)

5 thoughts on “STL Performance

  1. gyakoo

    Como sabes la STL no es más que una especificación de interfaz y de órdenes de complejidad en sus operaciones. La implementación puede ser y es distinta, mientras cumplas con sus especificaciones .
    Pero claro, no dice nada de las constantes multiplicativas de estos órdenes que varían enormemente debido a la cantidad de formas diferentes que se tiene en c++ de hacer y optimizar las cosas y dependiendo de los desarrolladores.
    ¿Has probado a utilizar otras implementaciones como stlport o eastl (Electronic Arts implementation)? Quizás alguna vaya mejor.
    Entiendo que con el code bloating de las stl así como por una inadecuada utilización de las mismas (debido en su mayoría a no saber cómo internamente implementa/representa los contenedores), muchos programadores se tiren de los pelos, pero también me pregunto ¿cuántos de esos desarrolladores han investigado los órdenes de las operaciones y qué ventajas de ofrece cada contenedor dependiendo de cada situación? Escribí un post no hace mucho, relacionado con esta materia.
    En resumen, en mi humilda opinión, las stl ahorran muchísimo trabajo, y es muy difícil conseguir tener una librería propia de contenedores tan genérica y más probada que la stl. Yo no la usaría para todo, evidentemente, pero para la gran mayoría de cosas, incluso para muchísimas de las partes de un juego, es una opción, que bien utilizada más que aconsejable.
    Saludos!

    1. Alvaro Martin

      Pues no había leído el post!
      Queda patente en tus test que las STL ( la implementación que utilizaste : ) son una buena opción para el desarrollo. Si nos ponemos “tikis mikis” siempre podemos optar por un Array con una funcionalidad básica de inserción y busqueda. No he hecho la prueba pero, para que la inserción y búsqueda tenga lo mejor de los 2 mundos, vector y map, si tengo un array de [uint64] y hago las inserciones con miArray[i] = Objecto; teoricamente la inserción debe ser constante ya que la memoria está alineada cual vector.reserve. Y si hago un acceso miArray[id] debe ser igual de rápido que un map, no?

      No se si me he explicado bien pero a ver si esta semana hago una prueba extendiendo la tuya con una implementación ad-hok, es decir que no sea de propósito general como las STL.

      PD: no logro linkar mi blog por Google Buzz que es el método que uso en plan RSS Reader. Creo que tu tampoco lo tienes conectado con tu blog de blogspot, no? o puede ser que no te tenga entre mis contactos de GMail? jumm…

  2. gyakoo

    Hombre, ya sabes, el posicionamiento en un vector es más rápido que en un map, es un acceso a un offset de memoria. En un map primero hay que hacer un hash de la key, y luego, según si es tabla o árbol, navegar hacia el elemento teniendo en cuenta las distintas entradas de las colisiones de la key. Rápido aún así, pero no tanto como en un vector evidentemente. Si sabes el número de elementos que tienes y su rango, podrías meterlo en un vector, incluso con algún tipo de transformación para cambiar el rango de [x,y] a [0,n), pero claro, no vale para otro tipo de keys como cadenas. Aún así, para cadenas, mejor usar valores hash que las propias cadenas en sí, o sea, representar las cadenas constantes como números (idealmente únicos). El almacenamiento y su manipulación es más rápida, aparte de que no tienes que tratar con heap, pero claro, tienes que andar convirtiendo a hash… Todo tiene su pro y contra, según para qué lo uses y dónde.

    En otro post en mi blog, implementé una tabla hash para un diccionario, te puede ser de utilidad, tiene el source.

Deja un comentario