Sounds like one or more of the following:

a) poor implementation of the stack using a vector.

b) poor implementation of the vector class itself by the compiler's library.

c) timing debug build rather than a release build with optimizations turned on.

d) The dynamic array has been "hand-optimized" to take advantage that a stack is being implemented, while the vector implementation has not been optimized.

e) As _uj pointed out, comparing apples to oranges, making the test unfair. For example, start out with a stack that can only hold one element (it has been allocated with new[1], not new[100000] or something like that). Now, each time you push an element onto the stack, you call new[] again, along with delete[] to make room for the new element. Do this for 100,000 elements. Now time your tests against vector. Unfair? No it isn't if you did not call "reserve()" for the vector implementation. Conceivably, an "unreserved" vector may be doing all of these calls to the allocator, (although it isn't likely, it still is possible), so to be fair, your program should be making these same calls.

I have coded a small example that randomly accesses the array and vector that have 1,000,000 elements, and there is no difference between using a vector as opposed to a dynamically created array if the proper functions are used and a release version is timed. There are no "hand-optimizations", just raw accesses to the array and vector (the only optimization is calling the reserve() method of the vector class -- something any experienced C++ programmer would do if they know in advance that they are going to grow the vector dynamically by adding thousands of elements).

I will try to post it today or tomorrow, along with the timings.

Regards,

Paul McKenzie