The reason I thought that arrays were so much better was from this experiment. I just wrote to a big vector and then read back from it and timed it - similar to this:


Here are the results. As I figured, much of the time was due to using calls like push_back() and at().


But it still seems to take twice as long even with the best way of using a vector vs an array.

Thoughts? (I can attach the entire "test" program if you want, it was just alot of lines so I just gave the one example function)

Thanks,
Dave

sorry, double post!

A good comparison will use a dynamic array using new and delete, and resize() or the size constructor for the vector to set the size initially just like the array. A good test will also use comparable operations. Comparing direct assignment for an array with push_back() for a vector will be no contest for the array.

Finally, be sure to run in some kind of optimized release mode where your compiler's debugging code is disabled. On Ed's compiler, vector::operator[] is identical to vector::at() in debug mode. Comparing the unchecked [] operator for an array with a checked [] operator for vector is an unfair test.

Performance is tricky to guess about, but Edward would guess without seeing your code that you used a real array and not a dynamic array in the test. That saves an extra indirection step that the vector still has. But since you need the array size set at runtime, the array test doesn't fit your goals.

Ed would also guess that you tested in debug mode without optimizations. Any good library class will have a strong debugging framework, but that skews the results in favor of the array because the array is completely unchecked.

It seems we have more and more aimless talking here. What's an amusing statement:
Of course, you declare and maintain ALL data structures to store and retrieve values. The key point is: what for? It's an absolutely senseless debates about milli-microseconds while the author keeps silence about operations with these dynamically or statically or what else allocated data arrays/vectors/valarrays etc..

Pretty harsh, don't you say? I clearly did not know the difference in a lot of these things, hence my post on a forum....

And also, the question was indeed about the time taken to store and retrieve these values, not to perform any operations on them. If the answer is "it doesn't matter how you store them" then that is fine with me.

Sorry, don't take offence at my previous post. The point is that nobody stores and retrives data in the core memory for no particular reason. You want to process these data values, I want to process these data values, he/she wants...

You may fill the vector of 10000000 doubles for 50 milliseconds then process them for 72 hours (to solve 3D system of differential equations, for example) - or you may fill dynamically allocated valarray for 25 milliseconds then process it for 24 hours. May be, your program wants to calculate sum then print the only number and die. Feel the difference...
What's a problem? The problem is data processing. It's not a problem to allocate storage for 1000000 words. The problem is what you want to do with these lots and lots of them. If you have 10Mb text file and want to collect this text dictionary, you need store data in some kind of balanced tree, not in std::vector or array. May be, you have 100 GB raw array for data mining - then prepare it for loading to a proper OLAP system: read sequentially block by block, convert, rewrite to a mass storage device - it's the other story, "it doesn't matter how you store them" because of you can't "store" 100 GB in the core...

That's why I said about "aimless talking".