|Perl: the Markov chain saw|
Re^3: Because CPAN Needs More Templating Modulesby Discipulus (Monsignor)
|on Jun 25, 2017 at 09:17 UTC||Need Help??|
Your benchmarks make it clear. Also to have perl code directly into the template is a plus at least in terms of semplicity. I started programming before separation of concern was so valueted and most times I still prefere having all at glance, more if the project is little or minimal.
What I still wonder is about the dimension of the template itself. When I asked for some bench with big templates I was not speaking about big templates systems but about big template texts.
I mean, there is some performance degradation as the template goes bigger? You shown us a few bytes template: what happens for 10Kb 100Kb 1000kb ones?
I dont want you show all possible benchmarks! you was so kind to share this module and to answer me, I just want to know if you have some theorethical idea about it. If I have the time I'l try to enrich the benchmark you shown.
I suppose that your templates, being in memory coderefs, will be surely fast as perl itself, but they must add their memory footprint into the main process of the program, obviously.
Is this the same of having the template cached? Or the caching ability of Template::Toolkit and others, acts differently? I ask this in the perspective of a persistent application.
Docs of Text::Xslate point also to a very exhaustive comparison, if bit aged, between template systems: at Sam Graham's website he used his Template::Benchmark to extrapolates results. Where your module would go?
That said your module will be for sure a good choice for simple things, being all at glance and very perlish, and a good candidate for bigger projects, possibly persistent ones.
Sorry if I abused of you patience and thanks you again!
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.