|
I guys,
I’m mostly lurking here, but it doesn’t mean that some of my ideas are not good J
The tiny benchmark thread made me realize something. Although, mono’s short time goals seem to be ‘get bug free and finish implementing’. I think it would be worthwhile to also take into account execution speed as one of the design goals.
The idea is simple, I guess that presently, people (a) find a failing unit test, (b) fix the code until it passes, and (c) test that the other unit tests are still passing. Then (d) they might even review the code to see if they can refactor it a bit.
It would be interesting if the phase (c) would also give performance results of the changes, i.e. information on how the change affected the performance of mono. That performance testing should actually be automated daily on a single box that runs nothing else (project wise).
When coding there are always different design criteria, and I think that if the developers see that the performance is increasing or decreasing because of changes it might make them more aware of the performance impact of the coding patterns they are using.
I know that usually, performance is always relegated to last. However getting a framework in place to measure performance might be started now. The benefits of such a framework might then be felt sooner in the development cycle as opposed to later.
Feel free to ignore me J
Phil
PS And yes, I could help write some of those performance tests if they would be used daily.
|
- Re: [Mono-list] New unit test proposal Philippe Lavoie
- Re: [Mono-list] New unit test proposal Miguel de Icaza
