Almost every application must be made to run faster; some sooner, some later. Performance tuning of applications has long been a dark art, understood by few and riddled with terrible pitfalls. Stories abound of optimization projects that took weeks but yielded a pathetic 2% decrease in total run time. Don't let this happen to you. The class will begin with a brief introduction to the basic concepts of performance tuning. We'll then launch into two practical case studies of real programs and how to make them faster. In the process we'll see Perl's most useful benchmarking tools, including the standard 'Benchmark' module and why you should avoid it. Throughout, the class will emphasize a rational, cost-benefit approach to performance tuning, discussing how to decide when to do performance tuning, alternative approaches, and presenting many amusing anecdotes and cautions about philosophical errors (such as the '1+1=0 principle' of optimizations) that can cost you time and money. Outline: Performance tuning is Hard: Schwartzian Transform example; user, system, and CPU time; ponies; wallclock time: I/O, CPU, and memory bound programs. Simple measurement tools: 'time', 'Time::HiRes', 'times()'; Simple benchmarker; 'Benchmark.pm'; Heisenberg uncertainty principle. Profiling: Mail folder analyzer case study: 'Devel::DProf', the 90-10 rule. Mail folder analyzer revisited: when it's time to give up; the big picture. POD formatting case study; 'perldoc'; 'pod2man'. 'Devel::SmallProf'; 'smallprof.out'; Custom profiling tools: the Perl debugger hooks, a trivial debugger, 'Devel::OurProf'. Case study: XML processing turnaround. Blunders: Pseudo-hashes; getting the wrong answer as quickly as possible; the wrong question; trivial benchmarks; 1+1=0; file editing; good advice; premature optimization; numerical calculation; crappy advice ; 'each' vs. 'keys'; Jackson's rules.