It's probably bad form to respond to one post twice, but the more I thought about this, the more the argument reminded me of the situation pre-1973 oil crisis, where cars were getting bigger & bigger, and less and less efficient. The solution to the effect of every extra hundredweight of chrome that was added to the outside; was to add more cubic inches to the engine. Petrol was cheap, who cared how much we burnt. Then suddenly petrol wasn't cheap anymore, and those tiny, clunky looking, economic Honda Civics and Nissan Sunnys that everyone had been laughing at, took over the world.

Unfortunately, the lessons of the early '70s have been forgotten, and here we are again with petrol prices going through the roof. Except that this time it's not because a few Sheiks in power decide to raise the prices, but because we're using it up at such a rate, it's running out.

Application code should programmed to be as efficient as is required by it's users--commensurate with correctness and maintainability. If the users are happy with it's performance, there is little mileage in improving performance further.

Library code should be code to be as efficient as is economically possible--commensurate with correctness and maintainability. The author of library code never knows what the demands and requirements of the applications that will use it will be. The more efficient it is (both cycles and memory), the less likely the application programmer using it is going to have to take extraordinary measures (like seeking micro-optimisations), in order to satisfy the requirements of it's users.

I wonder how long it will be before the Moore's Law bubble bursts?