FYI, just to avoid questions:
The last column is "total test time". I probably should not have included that here. You'll notice that in the second run, the Feedback Node test had a longer total running time than the other two, despite being shorter for the iterations. That's the jitter I was talking about earlier when I described our grid -- something hiccuped on one or more machines giving us a total test time for that one that was longer. The total time is the sum of how long every run took. The instance time (column 3) is the average of each... we have +/-0.00 because we had enough iterations to remove the error bars on that averaging computation (the computation was correct for more than the two significant digits reported).
If I ran these tests repeatedly, I would expect that which of the three had the longest total test time would be random. If after many repetitions on the grid, one of them was consistently the worst, that would indicate that something in the feature itself is introducing the jitter -- i.e., it has the best average run time, but the worst worst-case time. In such a case, any given run has a small but non-zero chance of showing the jittery one as the worst average time just because it happened to jitter a lot. This is why we monitor performance night after night, even when there are no edits made to the code base.
It is subtleties like this that are the reason I don't trust benchmarks not done on our grid or one of the very few customers that I believe can take these things into account. This stuff is hard unless you have lots of training and/or the right tools. 🙂
