Qt, Visual Studio 2013, and slow debugging

I have recently made the switch to VS 2013 and have ported my code to use it and the pre-built Qt 5.4 distros for VS 2013

I find that debugging has come to a complete standstill. Code that runs in a second or two in release mode can take an hour or more to run in debug mode even with no breakpoints set. After extensive googling, following suggestions, and getting no improvement, I came across the suggestion that because the evil Redmond company (thanks, RolandHughes) pushed run-time bounds checking down into the STL by default, this has resulted in orders of magnitude slowdowns in code that heavily uses STL and STL iterators (which mine does).

There is a way to disable this, by rebuilding your code with the macro _ITERATOR_DEBUG_LEVEL set to 0. I did this for the dozens of projects used to build my code. Now at the last step, I find that my Qt distros were built using the default value for this macro, which is incompatible and will not link with code built using a different setting. I don't want to go down the rat hole of rebuilding my Qt distributions from source, because it takes hours and hours and I can't assure myself that what I get is the same as what I get in a prebuilt distro.

Has anyone else using Visual Studio 2010 or later seen these problems in debugging?

Does Qt Creator use the evil Redmond debugger for code built using the evil Redmond tool chain?

Any solutions, advice, anecdotes, incantations, spells, or exorcisms would be greatly welcome at this point.

I've just decided to bail on this and live with the terrible debugging performance. I'll find conditions and data for my app which will allow me to debug it within a normal human lifespan. It isn't worth risking a Qt rebuild to overcome Redmond's stupidity.

Hi,

I'm using Visual Studio 2013 with Qt 5.4.1 x64 on Windows 7 x64 without any debug lag problems. Could you provide a minimal project to reproduce this?

Quote:

---

Could you provide a minimal project to reproduce this?

---

Sorry, no. We have done some simple timing tests on large STL collections (vectors, maps, lists, etc.), and find that STL iterator-based access in debug mode is sometimes more than a factor of 100 slower than using pointer, operator[], or at() to access the contents of the container:

VS12 _ITERATOR_DEBUG_LEVEL=2 (default)
[] time 0.115298
At() time 0.117018
iterator time 10.762087
pointer time 0.083324

VS12 _ITERATOR_DEBUG_LEVEL=0
[] time 0.098513
At() time 0.113322
iterator time 0.353778
pointer time 0.083505

VS9 _HAS_ITERATOR_DEBUGGING=? (default)
[] time 0.131453
At() time 9.326832
iterator time 9.254912
pointer time 0.083334

VS9 _HAS_ITERATOR_DEBUGGING=0 _SECURE_SCL=0
[] time 0.097890
At() time 0.364729
iterator time 0.361583
pointer time 0.084134

This was done by a colleague. I don't have his code but I trust these results.

Our production code uses iterators extensively. My debugging problems are due to these sections of code being executed repeatedly for certain sets of data, to the point where the ability to debug was effectively eliminated. My short-term workaround is to use smaller data sets :D

The longer-term workaround is to rewrite those critical sections of code to use pointer- or operator[]()-based access where possible or to replace the STL containers with something more friendly. You can see that even in release mode (i.e. equivalent to _ITERATOR_DEBUG_LEVEL=0), iterators are a factor of 3 - 5 or so slower.

We have also decided to bite the bullet when Qt 5.5 comes out and recompile it with _ITERATOR_DEBUG_LEVEL=0 along with all of our internal code.

I'm not using STL-based iterators. Looking the responses time I agree with you that this is the problem.