Performing a good benchmark is hard. It looks simple, but many times I've seen benchmarks posted on perlmonks which were utterly useless, as they weren't testing what they thought they were testings. Furthermore, the vast majority of the people writing a benchmark run the benchmark on a single data set. Noone seems to have a problem coming up with alternative code fragments to test, but to actually vary the size of the data set is much rarer.

Also, your advice of "Just test both solutions, use whichever is faster, then optimize that one" is just plain wrong. There's no point in benchmarking unoptimized code, and then decide which solution to toss away. Suppose you have algorithms A and B, benchmark them, and find A to be twice as fast as B. Now you toss away B, and optimize A. Suppose after optimization, A runs three times as fast; that is, 6 times as fast as the unoptimized B. But maybe it was possible to optimize B such that it runs 10 times as fast, making it faster than the optimized A. You wouldn't know, you've already (and too early) decided to go for algorithm A.

You should benchmark *optimized* code. And you should run it with a large range of data set sizes.

Abigail