Martin Fowler tells a good story about the Chrysler payroll system.
After spending some time noodling what was probably needed fixing, Kent
Beck broke out a profiler. Turned out the real problem was creating
empty date ranges. ("It takes awhile to create nothing.") They created a
constant for the empty date range, and adjusted a single factory method
to return that instead of creating a new empty date each time.
Performance instantly doubled. Similar interations with the profiler
resulted in gains of several magnitudes. The changes that needed to be
made were rarely anything that the developers expected.Most of us realize that applications, like most anything else, spend at least 80% of their time doing 20% of the task. Which means that in any optimization, it's important to first determine that what you are doing is in the zone where the application spends most of its time. Otherwise whatever you do gets lost in the rounding. Fowler's advice is to start with the premise that the best optimization is a good design, which is often also the easiest code for the compiler to optimize. And then see if you a problem that needs fixing. The real benefit is that if you have a solid design, worthwhile optimizations are easier to make. Given the empty date example, since it used a factory method, they only had to make the change once, and the entire applicaton benefitted. Keith Bacon wrote: > > Ted, > "Early optimization is the root of all evil." > I like that! > > A manager told me that maintenance bills for old > systems were hugely inflated because of bloated > optimisation logic that saved a little bit of hardware > cost for a few years. > Mind you plenty of systems have been written that > won't perform on any network/hardware - you have to > volume test & optimise critical systems. > > Also I'd rather maintain a system that has logic in > java than in javascript that's tangled up with html! > Keith. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
