In many ways I think vectors can offer us the best of both low level and higher level coding paradigms, with the flexibility and automatic memory management of dynamically sized containers, but with the the performance benefits of low-level direct access to a contiguous data buffer and the simplicity of integer element indexing. In fact, the SDK now uses vector-like data structures almost completely to the exclusion of pointer based data structures (even for things like dynamic meshes). See this presentation by Stroustrup and this blog post, for example.Īnd this has certainly been our experience with PathEngine.
Generally speaking, contiguous buffers are good, and memory allocations and scattered access patterns are to be avoided, and we're advised to prefer std::vector over std::list in most situations. In this post I'll discuss the main ways in which STL style vectors are applied in PathEngine, and look at some of the key performance and memory points coming out of this. I remember coming to C++ (and the STL) from a background in lower level programming, and finding STL vectors a bit surprising, with the idea of amortized constant time complexity and so on.Īnd then it was actually something of a minor revolution just to be able to set up a contiguous data buffer, without any significant programming effort, and without knowing the maximum required buffer size in advance.īefore we had C++ and the STL I remember a common source of errors being dynamically generated data overflowing fixed buffers, which is something we just don't see any more, thanks in no small part to the humble vector (and brethren).īut convenience can come at a cost, and there's some stuff you need to be careful about when applying STL vectors in performance critical situations.
0 kommentar(er)
