Jump to content
  • Advertisement
Sign in to follow this  
Agony

std::vector::resize slow in debug mode

This topic is 4811 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, I tried looking for already written suggestions on this, but I couldn't come up with a successful search string for Google. I'm so worthless. [smile] I've just experienced a problem where std::vector::resize() is painfully slow in debug mode. Up until now, I've had no problem with debug code. It was a bit slower, but didn't affect things severely. Now I'm having trouble debugging anything. Release mode works just fine; all the optimizations properly cut out the crap that isn't needed. It seems to be specifically caused by the copy constructor being called on every element (around ~4 million or so), inside the internally called insert(). (Specifically, it's the fill() function, but that's probably specific to VC6; yes, I know, I said VC6 in reference to the STL.) The vector is just a vector of unsigned chars. I know it's not the allocation itself; I call a reserve just before that, and it works quite quickly. It's just the resize that is slow. Theoretically, I'd like it best if it didn't initialize all the elements to anything at all (since I copy data from elsewhere immediatley afterwards), but if I can't get this to work right, I might fall back to simply using new and delete in this one case. But if there is any settings I could change, or any minor code changes I could make, I'd love it. Debug mode should still be able to optimize some things.

Share this post


Link to post
Share on other sites
Advertisement
As far as I know, SC++L containers only consider their content as objects, so there is no way for it not to use copying constructors when resizing, especially vector, since when you call resize, it must allocate all objects that are not yet to match the size you asked it, it's exactly what it should be doing.

If your objects are large and are not meant to be copied, you really should use some sort of smart pointer or resort to manual pointer allocation/deallocation.

Share this post


Link to post
Share on other sites
#pragma optimize got me really excited last night, but I couldn't try it until this morning. Sadly, it didn't work, though I'll definitely remember it for possible future use. I tried all sorts o' things, but I was probably using it wrong.

Regardless, I found a solution. I've heard a lot and read some stuff regarding allocators, I definitely knew they existed, but I hadn't messed with 'em yet. But I saw that my problem was with allocator.construct(), which was calling placement new for an unsigned char. I created my own allocator that overrode construct() and destroy(), making them do absolutely nothing. I don't know if that's an ugly hack or not (though it sounds reasonable enough to me currently); regardless, it works and I am happy and can actually debug the rest of my program. Yay debugging.

[edit]Sneftel, I just reread your statement, and I can't believe I totally forgot inlining. Geez, that probably would've worked. That's what you get when you read the solution in the evening, and then implement it in the morning; you forget half the solution, but don't realize that you forgot half. Ah! Smack me if you wish. [smile][/edit]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!