On 2011.11.22 11:02 AM, Eric Wilhelm wrote: >> By being THE testing framework, it places an upper bound on how fast >> anyone's tests can be. 10 .t files per second, no faster. That >> sucks. > > I agree. But, with XS mouse, you're only cutting the startup time to > 0.07s from 0.09s, correct? And really, 14.3 .t/s also sucks vs the > 50 .t/s with v0.98, no?
That's before any further optimization is done. XS Mouse buys us 20ms before we even start. > Is there a way to remove some of the work Mouse is doing at startup? > What is it doing? I don't know about Mouse, but I know Test::Builder2 is eating 13ms building up all the different types of Results at compile time in TB2::Result. Results are over-engineered. I have a not-too-old branch to simplify them. Some of the time is spent applying roles and generating accessors and there isn't much to be done about that in Test::Builder2. Performance enhancements in Mouse itself would be appreciated by all. I've added a branch called "gonzales" which uses Mouse directly. You can experiment with that and NYTProf to examine compile time performance issues yourself. https://github.com/schwern/test-more/commits/gonzales > I did once suggest a pre-loading / forking harness (along the lines of > Test::Aggregate), though it would probably be much better to make the > test code start faster rather than need to work around it. That's an interesting idea. FWIW Test::Aggregate should become much easier with Test::Builder2. Instead of the shenanigans it goes through to merge tests together, it can just intercept set_plan events and turn them into subtests or just scrub them out entirely. -- 184. When operating a military vehicle I may *not* attempt something "I saw in a cartoon". -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
