Sign in to follow this  
stein

specific files in release?

Recommended Posts

stein    164
Hey all! I have some cpp-files, in which I have a some code that uses a lot of time. It's _alot_ faster in release, and since I never need to debug these files, I was wondering... What should I do, so that these files are compiled as in release, even when compiling in debug? I've tried the #pragma optimize("atp", on), but that doesn't seem to do much of a difference. PS: These files are using std::vector a lot. Thx in advance :)

Share this post


Link to post
Share on other sites
XXX_Andrew_XXX    340
Let me take a stab in the dark...

VC.NET and you're calling vector.at() frequently? We had huge problems with this recently. In debug mode a very simple profiler couldn't measure the code, whilst in release performance dropped to about 3fps. The C++ Gurus (Meyers, Sutter, Stroustrup and co.) recommend the use of iterators to maximise peformance.

If the calls to at() are in deeply nested loops they could cause branch mispredictions because they are range checked. The most common operations with vectors iterate over the whole sequence, during which you don't need to have range checking enabled. Using iterators removes the need for the irrelevant (in this case) range checking.

Even more, don't calculate vector.end() each time through the loop, hoist it outside, and because it never changes use a constant iterator. Also make sure that all uses of the stl use prefix increment operator to prevent the copy, although with most vectors this should not be an issue.

And if all this sounds like far too much work, refactor code to use std::for_each or a modified version of for_each which you can pass a whole container to. For loops with small bodies boost::bind, boost::mem_fn and boost::lambda are ideal to prevent having to write huge numbers of very small functors, loops with larger bodies you should be writing functors.

If the vectors contain small(ish) sized data you may want to look at a pool allocator like boost::pool or Loki's small object allocator, which might have some performance effect if you are frequently creating temporaries.

Don't forget, conventional wisdom still applies. Prevent copies where you don't need them (pass by reference where possible). Choose appropriate containers - if you're frequently sorting or searching make sure that a vector the most appropriate container. Hoist things out of your loop that to prevent recalculating invariants each iteration. Make sure that your algorithms run in acceptable time O(???) and that any contants in the algorithm are acceptable.

Share this post


Link to post
Share on other sites
stein    164
Cool... Thanks, I'm gonna try out some of those tips.
But, isn't it possible to have the file compiled more or less the same way, as it is in release? I mean, with the same compiler-optimizations - and so that it also applies to the libraries it uses.

Share this post


Link to post
Share on other sites
XXX_Andrew_XXX    340
The problem is that C++ compilation units should always be compiled using the same version of the C-runtime library, and if you have multiple versions something will break.

/MD Compiles to create a multithreaded DLL, using MSVCRT.lib
/MDd Compiles to create a debug multithreaded DLL, using MSVCRTD.lib
/ML Compiles to create a single-threaded executable file, using LIBC.lib
/MLd Compiles to create a debug single-threaded executable file, using LIBCD.lib
/MT Compiles to create a multithreaded executable file, using LIBCMT.lib
/MTd Compiles to create a debug multithreaded executable file, using LIBCMTD.lib


For example, you might be tempted to move the code in a static or dynamic library, however if you try this you'll either get a link error, or even worse a difficult to diagnose bug at runtime. It's not worth the heartache - I've heard (and said) 'I'll never need to debug this' far to many times and been proven wrong ;-)

Another thing you might want to consider is turning on inlining for debug. In some situations this could give a good performance boost, but it is worth profiling first.

Share this post


Link to post
Share on other sites
Toolmaker    967
The only feasable way I see is to compile the code into a release DLL. You wouldn't be able to debug the DLL, but it will have full speed.

Toolmaker

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this