fidel;17190 wrote:
Overhead is huge, It may slow down tests 6X-10X times.
RDI UI interface looks a bit awkward. Quick Navigation, filtering, most important things are absent.
There is no way to collect RDI data only for specific tests, (and draw arrows for rest)
I just wanted to check if you've looked through the
RDI guide here on the website. There's a lot you can do to control the cost of RDI in terms of its performance. I would recommend lowering the method data limit somewhat and perhaps look into disabling it for some of your tests using EnableRdiAttribute.
Quote:
I would like to see also "FOCUS mode" (even without RDI) when only specific test(s) COVERAGE is being shown. (all green circles for rest tests are hidden/semi hidden/transparent)
This will be nice for live quick troubleshooting, without that its hard to distinguish exact test flow.
There is a context menu option allowing you to show coverage for specific tests only. This does also affect RDI.
Quote:
In general I found that when I need dump output, its better/quicker to use Console.Writeline + write couple extra IF blocks
instead of turning on heavy RDI, I use Ncrunch Cache+ RDI on ramdisk by the way.
If you need to go through the trouble of turning RDI on every time you want to use it, then yes, I would expect this would be faster. The intention of RDI is to have its data very easily available every time you need it. If you're turning if off because the performance hit is too high, it'll probably only be useful in very specific situations.
Quote:
If its possible to disable Collecting data but keep Arrow flows, could be useful.
Setting the string length limit extremely low will probably get you close to this, but I would expect that the overhead from tracking control flow will likely be responsible for much of the instrumentation cost you're experiencing.
Quote:
I really love Ncrunch, and I would like to extend it with some features which I miss, but there is no way to write community extensions.
Sorry. We have planned for years to build an API, but it's been hard to find time for this with everything else we've been building. It is also something we have been putting off because for several years much of the product has been in a state of flux, and it's hard to maintain an API when everything connected to it keeps changing.
Quote:
Sometimes also I encounter keyboard lock in VS (on different machines latest VS), probably caused by Ncrunch, but I have also R# installed, I will try to monitor that case and report it.
Fix is only to restart VS, Keyboard literally doesn't work.
Let me know if you find a way to reproduce this. It's not easy to track down problems like this in an IDE with multiple vendors running code in the same process.
