I recent got a report about NH Prof performance issue. I am used to combating them by now, but this one was on a class all on its own.

While trying to capture profile from integration tests one has to select only a few tests to run. NHProf seem to choke on more than 10 sessions with ~15 traceable queries each on an adequate laptop...

Now, I know this can’t be right, I tested NH Prof performance on NHibernate’s integration testing. Over 3,000 sessions with tens of thousands of queries. So I asked for a repro and disregarded that.

Then I run into the problem. NH Prof suddenly started taking as much CPU as it could. I was very cautious in trying to figure out what was going on, since it is really not to my best interests to mess something up and lose the repro.

But it turn out that breaking into the debugger and just stopping every now & then and marking what the app is doing is a pretty good way to figure out what is going on. The application kept stopping in the XAML template for a statement. But I wasn’t feeding new statements to the application! For some reason, it decided that it should discard the existing statements and create new ones.

It took me a while to figure that one out, but I finally got it. Take a look at the following diagram:

Can you see the bug?

On the backend, for purposes of calculating the maximum amount of statements in the recent statements list, I was ignoring transactions. But on the UI, I was not. The effect was that every time the backend had a list that included transaction statements at the maximum amount, the UI would get it, treat transaction statements as normal statements and clear a part of the list in the UI.

We ended up keeping the UI very bust updating the same thing over and over again. Nasty, and quite hard to track, I am afraid to say.

The fix was literally a single line (making the UI treat the transactions as not important for calculating the size of the list).