Test::Builder1.5 is slow. How slow? About 3x slower than 0.98. Enough to
significantly impact test performance. For example, Spiffy takes 1 second
with 0.98 vs 3.3s with 1.5.
I deliberately didn't do any profiling or optimization while the design was
coming together. This avoided spending tim
I did some profiling and easy optimizations which sped things up quite a bit,
but it didn't translate into real world improvements. Turns out the real
problem is startup time.
use Test::More;
0.98
real0m0.021s
user0m0.016s
sys 0m0.004s
1.5
real0m0.092s
user0m0.083s
sys
On Fri, Nov 18, 2011 at 11:20:00PM -0800, Michael G Schwern wrote:
> I did some profiling and easy optimizations which sped things up quite a bit,
> but it didn't translate into real world improvements. Turns out the real
> problem is startup time.
>
> use Test::More;
>
> 0.98
> real 0m0.0
I'd think Michael has the interests of CPAN smoke testers in mind with
these performance benchmarks. You're right in that for the typical
developer, it's not significant.
-y
My bigger concern would be inclusion of Mouse in core as a dependency,
since the direction of Perl seems to be to have fewer core modules,
not more. I'd run that discussion by p5p/Ricardo before getting too
tied to Mouse.
Separately -- once the Perl core gets a MOP, maybe this gets
easier/faster
On Mon, Nov 21, 2011 at 5:30 PM, David Golden wrote:
> My bigger concern would be inclusion of Mouse in core as a dependency,
> since the direction of Perl seems to be to have fewer core modules,
> not more. I'd run that discussion by p5p/Ricardo before getting too
> tied to Mouse.
>
> Separately
On 2011.11.21 4:07 AM, David Cantrell wrote:
> But then how often does one need to 'use Test::More'? Not enough to
> bother optimising it, I'd say.
In every single .t file that gets run by just about everybody.
By being THE testing framework, it places an upper bound on how fast anyone's
tests c
On 2011.11.21 8:30 AM, David Golden wrote:
> My bigger concern would be inclusion of Mouse in core as a dependency,
> since the direction of Perl seems to be to have fewer core modules,
> not more. I'd run that discussion by p5p/Ricardo before getting too
> tied to Mouse.
Mouse won't be in the co
>
> From: Michael G Schwern
>
>On 2011.11.21 4:07 AM, David Cantrell wrote:
>> But then how often does one need to 'use Test::More'? Not enough to
>> bother optimising it, I'd say.
>
>In every single .t file that gets run by just about everybody.
>
>By being THE te
On Mon, Nov 21, 2011 at 5:35 AM, yary wrote:
> I'd think Michael has the interests of CPAN smoke testers in mind with
> these performance benchmarks. You're right in that for the typical
> developer, it's not significant.
Just to offer a contrasting viewpoint: if you're using TDD, you're
running
# from Michael G Schwern
# on Monday 21 November 2011 17:56:
>In every single .t file that gets run by just about everybody.
>
>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 m
On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm wrote:
> Is there a way to remove some of the work Mouse is doing at startup?
> What is it doing?
How much of Mouse is needed? Could Moo be used? (I ask without
having read the details of the OO breakdown of TB2)
-- David
On 2011.11.22 11:22 AM, David Golden wrote:
> On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm wrote:
>> Is there a way to remove some of the work Mouse is doing at startup?
>> What is it doing?
>
> How much of Mouse is needed? Could Moo be used? (I ask without
> having read the details of the OO
On Tue, Nov 22, 2011 at 10:49 PM, Michael G Schwern wrote:
> The major Mo[ou]se features that Test::Builder2 uses heavily is roles and
> attributes. It also uses types, coercion, meta classes and method modifiers,
> but those could be removed if necessary. I've tried to keep it simple to
> avoid
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?
# from Michael G Schwern
# on Tuesday 22 November 2011 20:19:
>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.
Was there some work in Moose
- Original Message -
> From: David Golden
>
> And I wonder if Role::Tiny could be extended to do multiple roles.
As an aside, while I'm sure that Schwern is using far more than just roles,
Role::Basic already handles multiple roles, is forwards-compatible with
Moose::Role and it adher
On 2011.11.22 8:06 PM, David Golden wrote:
> Attributes -- leaving aside types and coercion -- are you just talking
> about the sugar?
Mostly, and the sugar is very helpful, but not all of it.
There's also the potential runtime performance win. Mouse XS accessors are
significantly faster than pu
On 2011.11.23 12:15 AM, Eric Wilhelm wrote:
> Was there some work in Moose to generate and load pre-cooked classes for
> startup-time basics like the accessors and roles? It seems like being
> able to do that work once during `make` would be a big win.
I think that was wrt pre-cooking Moose's m
On 2011.11.23 12:49 AM, Ovid wrote:
> As an aside, while I'm sure that Schwern is using far more
> than just roles, Role::Basic already handles multiple roles,
> is forwards-compatible with Moose::Role and it adheres much
> more closely to the traits spec, particularly with regards
> to the commuta
On Thu, Nov 24, 2011 at 4:23 PM, Michael G Schwern wrote:
> I don't think cobbling together an OO system from bits and bobs, and then
> relying on it, makes more sense than using a fully baked one
Of course, that pretty much describes Perl OO in a nutshell until
Moose/Class::MOP came along. And
Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down
to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to
do NO EXTRA WORK AT ALL to include or maintain it. It just comes with
Test-Simple like any other .pm file in Test-Simple.
If I didn't bring it
On Friday, November 25, 2011 at 01:02 PM, Michael G wrote:
> We did it once with Test::Harness::Straps, though not nearly that well
> thought out, and it worked.
Do you know anyone (besides me) who used it?
> I do see a work around. Document that TB2::Mouse can be used, but you MUST
> add it a
On 2011.11.25 3:04 PM, chromatic wrote:
> On Friday, November 25, 2011 at 01:02 PM, Michael G wrote:
>> We did it once with Test::Harness::Straps, though not nearly that well
>> thought out, and it worked.
>
> Do you know anyone (besides me) who used it?
I know I dealt with some DarkPAN users, b
On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern wrote:
> Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down
> to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to
> do NO EXTRA WORK AT ALL to include or maintain it. It just comes with
> Test-S
Once again, I would like to rein this all in.
Employing a counter-factual, the WORST CASE is that p5p has to ship a single
110K file which they never have to touch themselves.
I am unable to get excited over the consequences.
Let's keep our heads. The whole argument against TB2::Mouse is predic
> From: Michael G Schwern
>Let's keep our heads. The whole argument against TB2::Mouse is predicated on
>the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance
>hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle
>for p5p and/or CPAN authors... we
On Sat, Nov 26, 2011 at 9:58 AM, Ovid wrote:
>> From: Michael G Schwern
>
>
>>Let's keep our heads. The whole argument against TB2::Mouse is predicated on
>>the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance
>>hassle for p5p. If the alternatives will cause EVEN MORE ma
On Saturday, November 26, 2011 at 12:44 AM, Gabor Szabo wrote:
> I can just imagine what people outside of the Perl community
> will say when they see such code in the official distribution of Perl.
The same things they already do?
-- c
Gabor Szabo schrieb am 26.11.2011 um 10:44 (+0200):
> On Sat, Nov 26, 2011 at 9:58 AM, Ovid
> wrote:
> > Rename TB2::Mouse to something like
> > TB2::_U_R_A_MORON_FOR_USING_THIS_ and I
> > think the problem will take care of itself.
> I can just imagine what people outside of the Perl community
Michael G Schwern schrieb am 18.11.2011 um 20:24 (-0800):
> The idea would be to continue to ship a copy of
> Mouse::Tiny as TB2::Mouse, that takes care of the
> dependency loop, but to only use it if a good enough
> version of Mouse is not already installed.
>
> To mitigate risk of a new version
Ovid schrieb am 25.11.2011 um 23:58 (-0800):
> Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_
> and I think the problem will take care of itself.
Or what about an addition to TB2::Mouse's import routine?
sub import {
# prevent unauthorised use
my $calling_pkg
On Fri, Nov 25, 2011 at 11:58:48PM -0800, Ovid wrote:
> Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_ and I
> think the problem will take care of itself.
Or just add some doco to it thus right at the top of the file:
=head1 ALL THE DOCUMENTATION
This module is for
33 matches
Mail list logo
