Instrumentation taking a long a time to execute.

LegacyForum

I have a very large application, that normally takes about 3 minutes to perform all its memory allocations. It never seems to finish even the allocation phase with insure. I let it run all night, in the morning it was still allocating. One of my co-workers said that insure enters an infinite loop whenever it encounters a c++ "continue" statement. I interrruped several times in the debugger and it didn't seem to be in any sort of infinite loop, just a very slow one. I'm only interested in leak detection. Is there a set of parameters that will speed up the running?

LegacyForum

Because insure operates on the source itself it's hard to say with 100% certainty why you are getting such a dramatic performance hit. The only way to really be sure of why this is would be to take a look at what it is trying to do during the time when performance is hit the hardest. This can be done in the debugger on your system by checking the stack trace a few times when it's going through this area. Because the debugger would show your routines as well as insure's routines it would give us a better idea of what it's trying to do.

From what you describe though one thing that you might try is adding the options

insure++.leaksearch off
insure++.suppress leak*
insure++.summarize leaks outstanding

This because one of the most time consuming tasks insure by default will go through is that if it thinks it might have found a leak it will double check itself prior to reporting this by searching through all of you memory and making sure it's really a leak. With large amounts of allocations this can take some time doing this double check on every allocation. Using the leaksearch off option will turn that off. The downside of doing that is that if you do then that double check is not taking place and therefore you may get a false positive reported for a leak that would otherwise have been found to not have been a leak. This is why you would also want to use the "suppress leak*" when using "leaksearch off" .. Lastly because I'm sure you would still like to know if you have any leaks or not you would want to have the "summarize leaks outstanding" option because with this option you would still get the leaks reported in the leak summary just not during runtime itself but because the summary is created at the end of the run it would need to make one search through your memory instead repeated sweeps through it and could be alot faster.