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 | [reply] |
Very good point indeed. Benchmarking first, then optimizing the fastest method is indeed the wrong way of doing this. I stand corrected. Abigail-II++.
CU
Robartes-
| [reply] |