Re: Relying more on Mouse

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/