All there have reserve functions.
reserve for mine and STL and SetSize in CArray.
The object of the benchmark was to compare all three in the same situation and see how they held up. I'm pretty confident that the spread will remain the same if all situations were tested.

In mine, the new operator is overloaded for custom memory allocation and for reserved memory operations. In this benchmark they all used default release mode new. So each had to grow dynamic. Which is important test since 90% of the time you don't know how much you are going to hold, such as a stream of data unless its polite enough to give you its size first. Many programs have the "Here's a bunch of data" philosophy.

If I did all the benchmarks again with reserved memory, you would find that, while they all would be faster, that the spread would be about the same.

All three have a operator[] for indexing and assignment.
Mine only has retrieval not assignment to protect against array out of index. Done on purpose to force users to use the provided functions. By doing so, I don't get calls where I get blamed for exceptions, well I still get blamed, but I get a nice fee when I find the problem in the users code.

Generally I don't use standard exception handling. I have a set of custom handling to let everything shutdown as nice as possible. In several programs I have complete custom memory allocation which takes care of any and all exceptions and cleans up. While NT up has better handling then the older versions, my software must run unhindered on any windows system with full error reporting, so I can't slap blue screens at people. That's why I return bool, which will drop into replace vector. I think its pretty decided (except with MS with doesn't always) that a bool return type means, it worked or it didn't, so anybody using the class will need to check to ensure success, which is faster and less code for them then try-catch blocks and if there's a full system error and if you're using my construct, you'll be politely informed of the error and the program will even offer to save, clean up and restart the program an bring you back you were, if possible.
So I use boolean returns often and let the programmer or program construct manage the error.

as for operator[], vector would probably be a little faster since all it does is get the begin pointer and add the offset. However if you're out of index it will crash. Mine on the other hand, verifies the index to be in bounds and will return an empty object type if it is, but I return a value not a reference so I can do that. The overhead for this check is minimal though and if you consider the time spent inserting the elements and the index time, the total time will still be in favor of mine, never mind the bonus of having a class that doesn't crash. Which again, I feel any SDK can have both performance and user safety, which STL doesn't provide. MFC has the full advantage over STL in safety at the sacrifice of performance.

So again, its user preference, if you want a class that will not crash no matter what values you give it, or what functions you call, as well as some kickin' performance, create your own and put all you want in it.
You want some good performance and the price of debugging, user safety and your head exploding while looking at one of the header files, then use STL.
And if you want something "Microsoft" safe, completely "Microsoft" compatible, at the expense of some serious performance, then use MFC.