When I debug my application,which need to read a big raw image file(800MB).I find the application is so slow when I open the IntelliTrace.
I found that the IntelliTrace's IO is too high ,But I don't know how to find the real reason 'why intelliTrace make my application so slow'.Why the intelliTrace write so many info to the .iTrace File,when I read the big raw image file.
Please give me a help,
InteliTrace records all steps application went through. Hence crazy I/O.
From Wikipedia:
Unlike a traditional debugger, that records only the currently active stack, IntelliTrace records all events, such as prior function calls, method parameters, events and exceptions. This allows the code execution to be rewound in case a breakpoint wasn't set where the error occurred.[114] Debugging with IntelliTrace will cause the application to run more slowly than debugging without it, and will use more memory as additional data needs to be recorded.
In order to allow you to backtrack during debugging it records how and when memory was changed so it can revert it to previous state when you step back in code (as opposed to classic debugger where you can only step forward).
By processing 800MiB of data you pretty much force IntelliTrace to record how it went through memory, together with all variables you use during decoding (multiplied by times you changed it - eg. loop length).
The answer to your slow debugging issue in InteliTrace is limiting what it saves, or even better, creating test environment. You can try making Unit Tests and/or test data file (much, much smaller than your current blob).
IntelliTrace doesn't record memory states. It records events that happened. By events I mean function calls or exceptions. You can configure what events to collect (Tools/Options/IntelliTrace/IntelliTraceEvent) and how much data to collect ("IntelliTrace Events Only" or "IntelliTrace Events and Calls Information" in Tools/Options/IntelliTrace). It won't be free to collect the data. And the performance depends on what events to collect, how much data and how many such events generated in the program. So you can do trade-off before you start debugging. For example, if you don't care about file access events, turn them off. Even if your program generate many of such events, they won't be collected and stored.
