Lags in the editor after opening the Metrics window

Hello,
I have previously written that I have some problems with the lags while I type in the VS when NCrunch is running. It was not happening all the time so I did not know where the problem was.
But I have done some investigations (I have simply pressed one letter and looked how smoothly it was typed in the editor). When I start VS it all works fine but at the time I open metrics window - then it becomes slow.
Could you please tell if there is something that can cause it? Is there is some stuff that starts being calculated after the first opening or something?
Ilya.
P.S. I have even put the working directory to the RAM drive but it did not help with this issue after opening the Metrics window.

Hi, thanks for posting!

The lag is being caused by the NCrunch overutilising the UI thread when keeping the Metrics window up to date. This can also be caused by the Processing Queue window on larger solutions. Basically, the component used to show the tree list is consuming more CPU than it should be during refresh and this can cause laggy behaviour in the IDE when the window contains a large amount of data.

I've been looking at ways to resolve this issue. Unfortunately it's quite a major problem and will likely only be resolved by completely replacing the tree list component (which would need to be done as part of a major revision).

Meanwhile, I recommend you avoid working in your code with the Metrics Window and/or Processing Queue Window open. The Tests Window isn't really impacted by this issue as its filters tend to reduce the amount of visible data involved.

I hope to have this issue resolved as part of a long term plan.


Cheers,

Remco

Hi, thanks for the reply.
I don't have the metrics window open all the time. It's really a hidden tab. So I open it, check something and then it hides. But this does not help really so according to your explanation it seems that the metrics window is still updated though it's not really visible. It seems like a simple fix to allow refreshes when it's really visible. So it should not be really a big problem because the common behaviour can be too look at the metrics and then hide it back. The problem that it seems it's still updated. Is It possible to fix it like that? Because metrics window is quite useful and I want to use it really.
Ilya

P.S. I have just checked that even when you close the metrics window by pressing X it does not help.

Hi -

I've just conducted a short review and your analysis is absolutely correct. Opening the metrics view kicks off a service that keeps it updated while it is open, but closing the view does not shut down the service. This is not behaviour by design.

I've added the issue to the list of things to be addressed in an upcoming minor release. It looks as though the only workaround for this otherwise is to restart the IDE after the metrics window has been opened.

Sorry for the trouble.


Cheers,

Remco

I hope you'll be able to fix it soon :) According to the workaround - that's how I do it now already :)

I have seen the new release contained a lot of bug fixes and features. But I did not find this exact one in the list. Is it fixed or opening of the window still makes the editor slow?

Hi,

I had a good go at trying to fix this one, but while attempting to do so I was unable to recreate the problem. Every time I closed the metrics window, the performance problem went away and the UI behaved itself as designed. I'm wondering if perhaps there is something else happening on your system, or if there is a variable that I haven't been able to figure out. Are there any other NCrunch windows that you have open at the time during the performance lagging?


Cheers,

Remco

I don't think I have anything special because I tried it right after VS was opened. I guess that you need a really big solution to see the difference. I have noticed that on small ones the problem did not appear. Perhaps it's just hidden. You have written before that you saw the problem as well.

I'm really sorry.. when I first looked at this, I did so via a code review, and it appeared that opening the Metrics Window would leave a refresh service connected even after the window was closed, which could cause the performance issue to exist even after the window was closed. When I actually tried to fix the problem, I realised I hadn't analysed it correctly, and that the service seemed to be operating correctly (i.e. the performance issue disappears when it is closed). I thus find myself in the rather unforgivable situation of having admitted to a problem that I can no longer find or fix.

The performance issue in general though (slow UI while the metrics view is open) definitely appears in every environment where a large solution is being used. A fix is planned for this in the V2 release. I'd prefer to have it in a minor release, but unfortunately it involves replacement of the entire tree component, which carries significant risk and may destabilise the product for the many people that now rely on it.

I don't see it as a big problem when it slow only when activated, but I have it when I close it. And by closing I mean that it's really hidden as a tab and not clicking the close button. So it would be fine if the lag is only when you really see the window. But the problem is there even when you don't. Only when you have opened it once. So you are saying that you cannot reproduce this problem anymore (opening a big solution, opening code metrics and closing it)? If so I can try to see what else can cause it.

This makes sense. At the moment, NCrunch can't identify a 'hidden' status, as this is something under the control of Visual Studio. So unless the window is physically closed (via the X), NCrunch will continue to keep it up to date and drag down on the UI.

Trying to limit the refresh actions to windows that are visible only is a bit of a rocky road of VS integration and/or visibility hacks, which I'm reluctant to try to include in a minor release out of fear that it may break already working VS integration. I think my preference would be to simply fix the performance issue entirely as part of a major release so that it doesn't matter what state the window is in. Sorry, this is probably the best I can offer at this stage.

I have double checked the behavior and it's slow when hidden but back to normal when closed. So I guess we have figured out how to reproduce it :) I guess it should be fine for now as I don't use this window very often. Will wait for a fix in a major release then. When is this planned by the way?

V2 is on target to be released in the fourth quarter of this year. The work to resolve the UI performance problems is already under way, so I can confirm that it will definitely be in the release :)

That's great :) Waiting for the version two.