Some recommendations:

• Try separating the two methods and use only timethis on each program. In each program vary what you are using the timethis on. E.G., once just like your listc subroutine is written. The next progrram might generate the data outside of the timethis block. Use timethis only on the computational snippet. If necessary, increase the number of data points, decrease the number of data points. Sometimes it is not obvious how a snippet will work when you tweak the characteristics of a data set. Some algorithms may work well on large dataset and poorly on smaller ones. Some may perform well with smaller data points than others.
• Try not to include "my" statements in your timethis code. These portions of the code will add bloat to your results (bloat the timed elements and decrease the iterations). I'm not saying that you shouldn't have done it as you did above, just that it might be worthwhile doing it differently and analyzing the results. It is a "good thing" to benchmark it in a "real world" scenario.
• Depending on how you intialize your data structures, you might need to be concerned about how your computer/OS caches data. Perform multiple iterations of each program (via a shell script or a batch file depending on your OS). It might even be worthwhile running a few programs in between that create large data sets. This might aid in preventing caching anomalies. I don't know how you generate your data set, so it may not apply to your situation.

  These are the things that come to mind immediately and I'm sure that there are many other things to consider as well. Good luck!

  Comment on Re: Benchmark.pm: Does subroutine testing order bias results?