STL Overhead
Author
How much overhead does a STL stack have? Is it a bad idea to use them alot? For instance I could either have a void*, allocate mem for my object, and then insert the data. Or I could use a stack for this particular problem. I would have a very large number of these objects all at one time (possibly hundreds) so is it a bad idea to use STL stacks or is there hardly any overhead?
-Greg Koreman
the STL offers extremely high performance with minimal overhead. Plus, it''s standard. So it''s portable.
bottom line: use it. you won''t be sorry.
bottom line: use it. you won''t be sorry.
quote:Original post by Greg K
How much overhead does a STL stack have?
Compared to what? An STL stack contains no more cruft than a very well-designed non-STL stack.
The STL is incredibly fast.
But you should always implement your own allocators, especially if you work with MSVC++ where heap allocation takes way too much time.
But you should always implement your own allocators, especially if you work with MSVC++ where heap allocation takes way too much time.
Yup yup.
You should waste your time writing new allocators without determining if they''re bottlenecking you, because that''s a great way to spend your time.
@_@.
You should waste your time writing new allocators without determining if they''re bottlenecking you, because that''s a great way to spend your time.
@_@.
quote:Original post by DrPizza
Yup yup.
You should waste your time writing new allocators without determining if they''re bottlenecking you, because that''s a great way to spend your time.
@_@.
LOL
Premature Optimization is the Dark Side of programming. Always a strong temptation, but never worth it.
quote:Original post by DrPizza
Yup yup.
You should waste your time writing new allocators without determining if they''re bottlenecking you, because that''s a great way to spend your time.
@_@.
I''ll point out that when STL pops off an objet, it doesn''t release that memory, it is returned to a pool for STL to use later.
Just make sure that you aren''t allocating/deallocating on the heap while runtime performance is critical.
It really depends on the type of container used in the stack
By default, it''s a std::deque, which actually shrinks when you pop objects off the top.
By default, it''s a std::deque, which actually shrinks when you pop objects off the top.
quote:Original post by daerid
By default, it''s a std::deque, which actually shrinks when you pop objects off the top.
No it doesn''t. deques are normally implemented by a vector of pointers to blocks of objects (notionally, at least).
As you fill the deque, it fills up a block, and adds new blocks only as necessary.
If you take an item from the deque, there''s no shrinking until and unless you empty an entire block; even then, I suspect the shrinkage would be up to the implementation to perform.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
