3 ms·
I'm one of the developers on musicbrainz, which is written using many of the technologies listed above. We're experimenting with moving from Template::Toolkit
by warp 15y ago
I'm one of the developers on musicbrainz, which is written using many of the technologies listed above.
We're experimenting with moving from Template::Toolkit to Xslate, we're having performance problems with Template::Toolkit.
Similarly we're seeing performance issues with Moose, and considering moving at least some of the code over to Moo.
If your project uses many CPAN packages, have a look at Carton. It has made our deployments infinitely easier.
- peteretep 15y agoPerformance issues with TT? Yowza... I am assuming you're using the XS version, helping it cache, have used a profiler to confirm that's really where it is etc. You must be serving a dramatic amount of dynamic traffic!
- mst 15y agoTT performance really can be a bitch. When I'm profiling Catalyst apps to improve performance I pretty much always assume that the first set of hotspots I'll find will be either Template Toolkit or waiting for database queries. The controller code and the Catalyst stack itself very rarely show up noticeably - and I'd suspect that Catalyst being the heaviest (or most featureful, depending on how you want to lookat it :) of the currently popular frameworks that that's likely to be true of everything else as well.
- mst 15y agoI wouldn't expect Moo to gain you much over Moose in terms of runtime performance, except in the very simple cases where Moo can use Class::XSAccessor instead of generating a perl accessor method. What you probably want instead is to profile and selectively remove type constraints - perhaps only for runtime but not for the test suite. Consider: package MyApp::AssertIsa; use strictures 1; use base qw(Exporter); our @EXPORT = qw(assert_isa); sub assert_isa { $ENV{SOMETHING} ? @_ : () } and then use Moose; use MyApp::AssertIsa; has foo => (is => 'ro', assert_isa(isa => 'Bar')); and flip the relevant env var for your test suite (or perhaps use one of the test harness env vars to trip it automatically for t/)