Re: VC STL performance (learning the right approach for the right job)
- From: "Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom>
- Date: Fri, 12 May 2006 15:46:51 +0100
I know vc stl sometimes slow than stlport,but i still use vc stl
It is fairly impossible for vendors to 2nd guess what programmers will do.
They have to provide a std container that for _most circumstances_ is
generally satisfactory.
For example with std::list, if you delete an element, does the allocator
save the old memory for next use (pooling it) or does it immediately free
the memory? Saving the nodes memory for next use will increase performance
but at the cost of hoarding memory. Neither choice is necessary the "right"
choice by the vendor.
There will always be situation where it is _specifically_ poor for the
programmers circumstances.
Providing alternative allocators goes someway to alleviating this.
Personally I wish the C++ standard had specified that all containers had a
compact() member function which guaranteed any surplus not-in-use-memory the
container was using was deallocated. The vendor could then freely recycle
memory knowing that the programmer could call this member fuinction if need
be.
Stephen Howe
.
- References:
- Prev by Date: Re: reverse_iterator problem
- Next by Date: Re: reverse_iterator problem
- Previous by thread: Re: VC STL performance (learning the right approach for the right job)
- Next by thread: std::vector and object copying
- Index(es):
Relevant Pages
|
