The Use Case for Event Monitoring

I'm revisiting my KenKen project, it's time for a little performance tuning - my unit tests take about 14 seconds to run, which is too long. One of the immediate fixes I need to make is remove the arbitrary limit of 10 calculation iterations, and swap it with some logic to decide if another iteration is likely to be useful.

The logic runs something like this

  10 if grid solved then quit

  20 if iterations >= 10 then guess a square, reset iterations and goto 10

  30 iterations++

  40 start an iteration, calculating as many squares as possible

  50 goto 10

After 10 iterations, the grid is unlikely to be solved using the rules I've created; what usually happens is that by iteration 4 there are no squares left that can be calculated using my rules, so iterations 5-10 are pointless. This is an example of some tracing that illustrates the point:

The logic I needed to implement goes more like this:

  10 if grid solved then quit

  20 if previous iteration resulted in no work then guess a square and goto 10

  30 start an iteration, calculating as many squares as possible

  40 goto 10


This set me on my way to investigating the Event Monitor, the story of which can be found here, The C# Event Monitor using Reflection

UPDATE
You're possibly the only person reading this, so thanks. I implemented the changes outlined above and it's shaved 1-1.5 seconds off the tests, so I'm happy. New tracing looks like this: