reserve() is handy for just such a thing - another potential improvement (though w/o having read in detail all of the thread, I could be off ;) ) would be to make your vector store pointers rather than full objects - this would have the benefit of NEVER having to call the copy constructors on your objects. Additionally, for LOTS more safety against memory leaks, store boost::shared_ptr<Platform> (or the new TR1 equivalent, if your compiler supports that). That way, you can create the Platform dynamically on the heap. wrap it in the shared_ptr, pass that to the vector, and forget about it. The pointer will be deleted when the last shared_ptr to it goes out of scope.
Or use a boost::ptr_vector, which would be ideal for this application and removes the overhead of shared_ptr.
Ah, yeah - forgot about those! Good call.
Just for completeness, does the Platform class have a copy constructor, copy assignment operator, or any other member variables that were not shown in the initial post? The only data shown was four SHORTS, which I assume (hope) are just short ints. If you are pushing back only 12 instances that use the default copy, I highly doubt that there would be more than one reallocation and that the copying would cause such a dramatic speed decrease.
Point being that you shouldn't have to worry about reserve when you are reserving space for 12 instances of a class that contains only 4 short ints. Something else caused your slowdown, and you just masked the issue by using reserve.
Could be. I noticed after going through all this my actualy program was calling ReadPos more like a few hundred million times. My loop broke somewhere into infinite because I never updated my older code to reflect the newer :/. But that doesnt stop that the vector seemed to cause the greatest speed decrease. When replaced with a static, it went alot faster.
Anyways, its fixed. Your codes are way above my head -,-. Is their any tutorial that explains your suggestions? -,- *Searches google*
>> Your codes are way above my head
Whose code? Most of the code here just uses vector, which you were already using. There are references available for vector and the rest of the standard library that you have hopefully found with your search.
>> Anyways, its fixed.
Unfortunately, it just appears to be fixed. Whether it is actually fixed or not we don't know because you haven't dug deep enough to find the details. It is often better to find the root of the problem than merely cover it up. I wouldn't be surprised if you had another "major slowdown" later on if you continue to work on this project.