Cumulative Processing Time

In the NCrunch Processing Queue, I'd like to have a column called "Cumulative Processing Time".
It would include the sum of the "Processing Time" column for this session.
This would help me in my refactoring efforts by allowing me to find the code that is currently a performance bottleneck.

Hi,

I'm just trying to visualise what you're after here ... Do you mean something like a cumulative total that adds its way down the Tests Window contents, summing up the Fixture and Test execution times?

Is there a specific kind of performance problem that you're trying to find?

Perhaps I'm misunderstanding the processing queue, but I've been using the "Processing Time" column to identify projects, tests, or groups of tests (depending on how NCrunch breaks it up) that are slow.

My thinking is that if there were a column that had a value that had the last processing time added to it every time that row is processed then it would allow me to see which items are not only slow, but are slowing me down the most at the moment.

I mainly work on a large legacy application and it takes time to partition a project into multiple smaller projects in a sensible way. My thinking is that a cumulative view of the processing time would very clearly highlight which projects are slowing me down the most and need to be partitioned so as to either improve performance or reduce the frequency of rebuilds and retests.

Sorry - I misread your post and was trying to think of how such a feature could be applied to the Tests Window, when you were talking about the Processing Queue.

What would you see as being the main advantages of the cumulative total as opposed to simply sorting the tasks based on their processing time?

I tend to find that while I'm working on one particular feature there are a number of projects and tests that are impacted, while there are many more that are not.

A project that is the slowest to compile might only ever compiled once, while there are several moderately slow ones that are compiled often.

A cumulative measure would allow me to highlight which items I should focus on right now to improve responsiveness.

It's a nice to have for me, though I thought it might be an easy to add nice to have.

Right. Am I correct in my understanding that the problems you are trying to solve are:

As a user, given a processing queue full of tests and builds, when a change is made to the codebase, then I want to know how long I need to wait for a specific task to be processed.
As a user, given a processing queue full of tests and builds, when a change is made to the codebase, then I want to know which tasks need to be processed in order for a specific task to be processed.

Sorry, I'm trying to dissect this in detail as I get the feeling that the processing queue might not be the best place to solve it.

I think it's more like:

As a user,
Given a processing queue full of tests and builds,
When a change is made to the codebase,
Then I want to know, of the tasks that will need to be processed in order for a specific task to be processed, which ones will take the longest?
So that I can identify which tasks are slowing me down.

For example:
Lets say that all of my tasks are project builds and I have build times like so:

A 1s
B 10s
C 30s
D 60s

To build everything takes 101s.

Now lets say A -> B -> C -> D, then if I modify C then I incur a 41s build.

My original thought was that if I'm beavering away in C and end up triggering 10 builds over a period of time I might end up with something that looks like this:

A 1s 10s
B 10s 100s
C 30s 300s
D 60s 60s

In total 470s have been spent, and more than half has been spent on C, so that's where my biggest opportunity for improvement lies.

The overall goal is to provide a metric that will help me increase the ease I have in working with a particular section of the solution while I'm working on it since I'm mainly working on a large legacy project and I'd like to incrementally improve its performance with NCrunch.

Excellent, now I get it!

So basically we're talking about introducing a value held against each of the projects that is the sum of the time of all builds executed on this project since the engine was last reset. That should be easy, and useful! I'll see what I can do.


Cheers,

Remco

I think I confused the whole thing by trying to talk about tests as well as builds.

Thanks for your persistence :)