@chrisname: Calling "new/malloc( )" for each object is a serious performance issue; Ogre3d does this, which is partly the reason why it runs so slowly. Also, the internal memory management of standard containers isn't exactly the fastest or the most efficient, but it really does depend on the game's complexity and performance targets.
Well, my (2D) game engine's sprite class only loads each sprite once. Is that what you mean? Or would you have the engine allocate some of the heap with new and then use its own allocators to split it up so you don't have to go through the OS?
"Well, my (2D) game engine's sprite class only loads each sprite once. Is that what you mean?"
Sort of. Excessive requests for memory is a slow process. It's common practice to allocate large blocks of memory from the OS (~2MB to ~8MB in size) and then implement some sort of structure to sub-divide the allocated blocks of memory. When an application requests memory, it queries the implemented construct to locate a block of memory that's suitably sized (this is what my engine does), though, internal fragmentation is still a persistent problem when implementing a MMS. Note that allocating numerous small chunks of memory increases external fragmentation, so this is best avoided.
All memory allocations are made with "new/malloc( )" query the OS anyway to locate a suitably-sized block of memory, which is why memory allocations are slow.
Also when dealing with graphical resources it is usually a good idea to try and combine them into larger textures that way you don't have to always load another resource just to use another sprite animation or something. Because loading resources is very expensive performance wise.
I know a lot of frameworks provide a way to combine separate images into a single texture. So try and combine whatever you can while still having it be manageable.