I've been working on Template::Benchmark some more this week and I've hit a brick wall, one entirely of my own stubborn making.

One of the major roadblocks to releasing v1.00 is that I'm unhappy with the name of one of the major conceptual elements of the module: I want to come up with a better name and, it being a major element, I don't want to change it after I've moved to a stable release.

Naming things well is something I'm extremely fussy about and one I've thought about often, so the factors that make a good name seemed like a worthy topic for this week's blog.

Last week, in "Monkey-patching Benchmark.pm to auto-correct custom controls", we covered how to monkey-patch Benchmark.pm into giving us the results we wanted, and saw that one alternative method was to wrap the module instead.

This week, we investigate how to do this, and see what unpleasant surprises lie in wait when wrapping a procedural module.

In "Advanced Benchmark Analysis I: Yet more white-space trimming", I mentioned that you could automatically take into account the cost of your control benchmark and eliminate it from the rest of your results.

This blog entry shows you how to monkey-patch Benchmark.pm to let you do just that.

Today I released a new beta of Template::Benchmark (v0.99_07) and one of the changes, along with the addition of 4 new template engine plugins (Tenjin, Template::Tiny, Text::Template::Simple and NTS::Template), is that it splits the author/release tests away from the install tests.

This was a royal PITA, so I thought I'd cover the how and why of what was done.

In my previous blog entry, "Advanced Benchmark Analysis I: Yet more white-space trimming", I left you with the thought that our benchmarks changed with changing input.

This article shows you how to analyze those changes and how to draw conclusions from them.

Seems my previous blog, "Some simple "white-space trim" benchmarks" caught people's attention, and I've received some interesting suggestions and observations worthy of a followup article, this also gives me the chance to delve into explaining more advanced benchmark analysis.

So, deep breath, here goes.

Laufeyjarson asked on Monday, about stripping whitespace from both ends of a string. The comments contains lots of suggestions, but no hard figures, so I thought I'd reproduce them here along with the code used to generate the benchmarks - it provides a simple example of how to write a quick and reliable benchmark.