Type::Tiny::Manual::Optimization - squeeze the most out of your CPU |
Type::Tiny::Manual::Optimization - squeeze the most out of your CPU
Various tips to help you squeeze the most out of your CPU.
The simplest thing you can do to increase performance of many of the built-in type constraints is to install the Type::Tiny::XS manpage, a set of ultra-fast type constraint checks implemented in C.
the Type::Tiny manpage will attempt to load the Type::Tiny::XS manpage and use its type checks. If the Type::Tiny::XS manpage is not available, it will then try to use Mouse if it is already loaded >, but Type::Tiny won't attempt to load Mouse for you.
The following simple type constraints from the Types::Standard manpage will
be accelerated by Type::Tiny::XS: Any
, ArrayRef
, Bool
,
ClassName
, CodeRef
, Defined
, FileHandle
, GlobRef
,
HashRef
, Int
, Item
, Object
, Map
, Ref
, ScalarRef
,
Str
, Tuple
, Undef
, and Value
. (Note that Num
and
RegexpRef
are not on that list.)
The parameterized form of Ref
cannot be accelerated.
The parameterized forms of ArrayRef
, HashRef
, and Map
can be
accelerated only if their parameters are.
The parameterized form of Tuple
can be accelerated if its
parameters are, it has no Optional
components, and it does not use
slurpy
.
Certain type constraints may benefit partially from Type::Tiny::XS.
For example, RoleName
inherits from ClassName
, so part of the
type check will be conducted by Type::Tiny::XS.
The parameterized InstanceOf
, HasMethods
, and Enum
type
constraints will be accelerated. So will the Type::Tiny::Class manpage,
the Type::Tiny::Duck manpage, and the Type::Tiny::Enum manpage objects. (But enums will
only be accelerated if the list of allowed string values consist
entirely of word characters and hyphens - that is:
not grep /[^\w-]/, @values
.)
The PositiveInt
and PositiveOrZeroInt
type constraints from
the Types::Common::Numeric manpage will be accelerated, as will the
NonEmptyStr
type constraint from the Types::Common::String manpage.
the Type::Tiny::Union manpage and the Type::Tiny::Intersection manpage will also be accelerated if their constituent type constraints are.
The following simple type constraints from the Types::Standard manpage will
be accelerated by Type::Tiny::XS: Any
, ArrayRef
, Bool
,
ClassName
, CodeRef
, Defined
, FileHandle
, GlobRef
,
HashRef
, Ref
, ScalarRef
, Str
, Undef
, and Value
.
(Note that Item
, Num
, Int
, Object
, and RegexpRef
are not on that list.)
The parameterized form of Ref
cannot be accelerated.
The parameterized forms of ArrayRef
and HashRef
can be
accelerated only if their parameters are.
Certain type constraints may benefit partially from Mouse. For
example, RoleName
inherits from ClassName
, so part of the
type check will be conducted by Mouse.
The parameterized InstanceOf
and HasMethods
type constraints
will be accelerated. So will the Type::Tiny::Class manpage and
the Type::Tiny::Duck manpage objects.
The HashRef[ArrayRef]
type constraint can probably be checked
faster than HashRef[ArrayRef[Num]]
. If you find yourself using
very complex and slow type constraints, you should consider switching
to simpler and faster ones. (Though this means you have to place a
little more trust in your caller to not supply you with bad data.)
(A counter-intuitive exception to this: even though Int
is more
restrictive than Num
, in most circumstances Int
checks will run
faster.)
If your type constraint can be inlined, this can not only speed up Type::Tiny's own checks and coercions, it may also allow your type constraint to be inlined into generated methods such as Moose attribute accessors.
All of the constraints from Types::Standard
can be inlined, as can enum,
class_type, role_type and duck_type constraints. Union and intersection
constraints can be inlined if their sub-constraints can be. So if you can
define your own types purely in terms of these types, you automatically
get inlining:
declare HashLike, as union [ Ref["HASH"], Overload["&{}"], ];
However, sometimes these base types are not powerful enough and you'll need to write a constraint coderef:
declare NonEmptyHash, as HashLike, where { scalar values %$_ };
... and you've suddenly sacrificed a lot of speed.
Inlining to the rescue! You can define an inlining coderef which will be
passed two parameters: the constraint itself and a variable name as a string.
For example, the variable name might be '$_'
or '$_[0]'
.
Your coderef should return a Perl expression string, interpolating that
variable name.
declare NonEmptyHash, as HashLike, where { scalar values %$_ }, inline_as { my ($constraint, $varname) = @_; return sprintf( '%s and scalar values %%{%s}', $constraint->parent->inline_check($varname), $varname, ); };
The Perl expression could be inlined within a function or a if
clause or
potentially anywhere, so it really must be an expression, not a statement.
It should not return
or exit
and probably shouldn't die
. (If you
need loops and so on, you can output a do
block.)
Note that if you're subtyping an existing type constraint, your inline_as
block is also responsible for checking the parent type's constraint. This
can be done quite easily, as shown in the example above.
Note that defining a type constraint in terms of a constraint coderef and an inlining coderef can be a little repetitive. the Sub::Quote manpage provides an alternative that reduces repetition (though the inlined code might not be as compact/good/fast).
declare NonEmptyHash, as HashLike, constraint => quote_sub q{ scalar values %$_ };
Aside: it's been pointed out that ``might not be as fast'' above is a bit
hand-wavy. When Type::Tiny does inlining from Sub::Quote coderefs, it needs
to inline all the ancestor type constraints, and smush them together with
&&
. This may result in duplicate checks. For example, if 'MyArray'
inherits from 'MyRef' which inherits from 'MyDef', the inlined code might
end up as:
defined($_) # check MyDef && ref($_) # check MyRef && ref($_) eq 'ARRAY' # check MyArray
When just the last check would have been sufficient. A custom inline_as
allows you finer control over how the type constraint is inlined.
Coercions are often defined using coderefs:
PathTiny->plus_coercions( Str, sub { "Path::Tiny"->new($_) }, Undef, sub { "Path::Tiny"->new("/etc/myapp/default.conf") }, );
But you can instead define them as strings of Perl code operating on
$_
:
PathTiny->plus_coercions( Str, q{ "Path::Tiny"->new($_) }, Undef, q{ "Path::Tiny"->new("/etc/myapp/default.conf") }, );
The latter will run faster, so is preferable at least for simple coercions.
This makes the most difference when used with Moo, which supports inlining of coercions. Moose does not inline coercions, but providing coercions as strings still allows Type::Tiny to optimize the coercion coderef it provides to Moose.
Toby Inkster <tobyink@cpan.org>.
This software is copyright (c) 2013-2014 by Toby Inkster.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Type::Tiny::Manual::Optimization - squeeze the most out of your CPU |