Every cycle's sacred Every cycle's great If a cycle is wasted God gets quite irate With most people I've talked to, this approach turns into a religion p

Every cycle's sacred Every cycle's great If a cycle is wasted God gets quite irate With most people I've talked to, this approach turns into a religion pretty fast. In my opinion, you should use a naïve approach (within limits, recursive Fibonnaci definitions are exempt) until it becomes necessary to do things more efficiently. Of course this entails always keeping in mind who your users are and whether a certain design choice needs to remain in your code for a long time, something it seems this installer team didn't quite grasp. But always choosing the most efficient algorithm leads to a program where code that runs for two milliseconds every minute runs 10 times faster for 3 times your development effort, with 3 bugs introduced in the process because you weren't paying attention. How much time is wasted? On my machine summing a billion bytes row-wise takes 9 seconds, whereas summing them column-wise takes 51 seconds. The less sequential your data acccess, the slower your program will run. Yes, if you sum gigabyte-sized arrays all the time, this is definitely something you should worry about. But not all problems require this kind of attention to low-level details. Most of the time you are searching an 8-byte array, in which case the choice of binary search vs. linear search is irrelevant. Of course it pays to be aware of these things (you won't have to go hunting in the library when you hit a wall) but keeping them in mind at all times is more trouble than it's worth. There are more important things to worry about, for instance whether your unit tests cover every likely case.