The semicolon is an interesting case. I'm leaning towards not counting it, as I can't think of a case where the shorter of two solutions would turn out to be longer depending on semicolon sensitivity. If such a case exists, this would take further thought.

As for automated counting, my idle musing was to abuse the Perltidy code for that purpose.

I don't like the Benchmark.pm idea - you'd have to specify the exact environment (Perl version+patches, OS, hardware, modules' versions) to be able to decide on a reproducibly and unambiguously winning entry. It's just too fickle a goal.

Makeshifts last the longest.

The Benchmark.pm idea could be done if the code were submitted to run on a particular computer, if someone is crazy enough to risk something like that ;-)

Seriously, it could be done in the sense that everyone is able to confirm the results on his own machine with its specific setup. The format of submission would be a function that can be run using Benchmark so that the "competition" could be compared by just pasting the code and running the benchmarks.

I agree that you won't see a clear winner, but it would give those of us interested in raw performance a number of alternative implementations and hence an opportunity to learn. It's all about taking part, not about winning ;-)

Just my 2 cents, -gjb-

Update: It would be possible to get a machine/OS/etc. independent comparison by using some "gauge code", ie. a standard piece of code. The benchmark for the Perl Polo code would then be calculated proportional to the time it takes the "gauge code" to execute.