Quote:Original post by MaulingMonkey#define _SCL_SECURE 0
And _HAS_ITERATOR_DEBUGGING 0, to be on the safe side.
std::vector slow
And _HAS_ITERATOR_DEBUGGING 0, to be on the safe side.
Quote:Original post by Quat
Thanks for the replies so far.
One thing I recently tried was to stop using push_back. Instead, I just used vector::operator[], and kept my own size counter. This is now comparable to the array performance.
Quote:Original post by ToohrVyk// Bad: for(int i = 0; i < numVertices; ++i) m_vertices.push_back(v);// Good: m_vertices.insert(m_vertices.end(), v, v+numVertices);
FFS.
Quote:I noticed push_back has a conditional statement (in case it needs to resize). Do you think that is the extra overhead? I read hardware does not like branching statements.
This one should be quite well predicted, though.
Also, what is 'v'? And why do you need to recalculate this much geometry (is everything moving)? How much flexibility is needed?
(And what kind of geometry is that? A triangle between the centroid and every line segment on the outside?)
Quote:Original post by MaulingMonkey#define _SCL_SECURE 0
I had a similar issue in my code not so long ago. During my game-update phase, 80% (!) of the time was spent iterating std::vector's due to the checks it was making. I didn't know about _SCL_SECURE at the time, so I changed them all to do a C-style loop, which lowered the time to do an update from about 10ms to 2ms. I assume defining _SCL_SECURE to 0 would have the same effect though I haven't verified.
Good luck,
Geoff
Quote:Original post by MaulingMonkey
Also, Kwizatz is showing off the perfect way to get your .reserve()s wrong, you want:
Yeah, I though about the case when there are already elements in the vertex after I posted, but I did not point it out, thank you for doing so MM, and sorry about that Quat. [smile]
Quote:Original post by gdunbar I didn't know about _SCL_SECURE at the time, so I changed them all to do a C-style loop
Hooray, and that's why I don't like Microsoft adding these macros. The lowered performance (in the normal case, when you don't actively define/undefine the correct sequence of macros) just makes people drop the C++ standard lib entirely, and fall back to C-style code... Just how much security did that buy anyone?
I'm not a big fan of proprietary stuff like that either, but the first time I ran my program in 2005 upgraded from 2003 it caught several instances where I was doing bad things with iterators, so in that sense it was useful. IMO it should be disabled by default in release builds though.
Quote:Original post by SpoonbenderQuote:Original post by gdunbar I didn't know about _SCL_SECURE at the time, so I changed them all to do a C-style loop
Hooray, and that's why I don't like Microsoft adding these macros. The lowered performance (in the normal case, when you don't actively define/undefine the correct sequence of macros) just makes people drop the C++ standard lib entirely, and fall back to C-style code... Just how much security did that buy anyone?
Negative amounts.
One thing to watch out for is if you change the _SCL_SECURE and _HAS_ITERATOR_DEBUGGING defines and you're building a library, anything that uses the library should probably use the same settings too. I had a nightmare with my engine crashing randomly in release builds because I'd forgotten to add these defines into the release configuration for my test bed. To be honest, I ended up just switching to my own custom array class instead because I couldn't be bothered with all these special defines to make Microsoft's STL work quickly.
Quote:Original post by f8k8
To be honest, I ended up just switching to my own custom array class instead because I couldn't be bothered with all these special defines to make Microsoft's STL work quickly.
I personally would rather just change my compiler ;)
Quote:Original post by MaulingMonkeyQuote:Original post by SpoonbenderQuote:Original post by gdunbar I didn't know about _SCL_SECURE at the time, so I changed them all to do a C-style loop
Hooray, and that's why I don't like Microsoft adding these macros. The lowered performance (in the normal case, when you don't actively define/undefine the correct sequence of macros) just makes people drop the C++ standard lib entirely, and fall back to C-style code... Just how much security did that buy anyone?
Negative amounts.
I actually worked at Microsoft for 10 years (not in the developer tools division), so I understand why they made things the way they are. They believed that security was on the verge of becoming _the_ reason that people would stop using Microsoft software. So they took some pretty heavy-handed actions to fix the problem. It certainly is a pain-in-the-ass in this case though, to the point where it is legitimate to question their decision, as you guys are. I'm not sure where I stand; in my code I currently leave _SCL_SECURE on for checked builds but turn it off for release builds.
Geoff
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
