Sam's Blog entries for category 'benchmarking' Subscribe to feed for category 'benchmarking'

I've just uploaded Template::Benchmark v1.03_02, the first release candidate for v1.04.

This adds two of the features that have been on my long-term goals for this project: custom datasets, and per-feature repeats.

The first lets you supply your own data-structure to use within the benchmark templates (or choose from a presupplied list).

The second lets you choose on a feature-by-feature basis, how often that feature should be used in the generated benchmark template, rather than only choosing how often the entire template would be repeated.

Taken together, these two features allow you far greater control of the generated benchmark, allowing you to tailor it to fit your individual needs with greater precision, read on for more details.

Well, after 13(!) point releases, I'm happy enough with Template::Benchmark to make the first stable release.

v1.00 should be hitting a CPAN mirror near you sometime soon.

Now that it's officially released, I thought I'd go into a little more detail about what Template::Benchmark does, how it can be useful to you, what motivated me to write it in the first place, and some thoughts on where to take the project next.

As part of my development environment for Template::Sandbox, I maintain a suite of regression benchmarks, using Template::Benchmark against all previous versions of the distribution.

While a crude tool, it's something I find useful and thought I'd use this week's column to share how I automated as much pain away as I could.

Last week, in "Monkey-patching to auto-correct custom controls", we covered how to monkey-patch 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 to let you do just that.

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.

Some simple "white-space trim" benchmarks

Date: Wednesday, 3 March 2010, 15:38.

Categories: perl, ironman, benchmarking, trim, regexp, optimization, basic, tutorial.

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.

Browse Sam's Blog Subscribe to Sam's Blog

By year: 2010, 2011, 2012, 2013.

Or by: category or series.

© 2009-2013 Sam Graham, unless otherwise noted. All rights reserved.