Software Optimization Quotes

One of my most productive days was throwing away 1,000 lines of code.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

All software sucks.

I think Zelda 64 is utilizing about 90 percent of the N64 potential, ... When we made Mario 64 we were simply utilizing 60 to 70 percent. So we have come a long way I believe.

We shifted our philosophy from being a computer mapping group that would support planners to the idea of building actual software that would be well engineered. Because at that time, our software was not well-engineered at all; it was basically built with project funding and for project work, largely by ourselves.

I'm not of the opinion that all software will be open source software. There is certain software that fits a niche that is only useful to a particular company or person: for example, the software immediately behind a web site's user interface. But the vast majority of software is actually pretty generic.

There's only one trick in software, and that is using a piece of software that's already been written.

I have this hope that there is a better way. Higher-level tools that actually let you see the structure of the software more clearly will be of tremendous value.

My reply is: the software has no known bugs, therefore it has not been updated.

It's hardware that makes a machine fast. It's software that makes a fast machine slow.

In the practical world of computing, it is rather uncommon that a program, once it performs correctly and satisfactorily, remains unchanged forever.

For us, the real goal is to make it so that the software ecosystem is as healthy as possible.

Apple's advantage is that it designs and builds software together, so if the software isn't excellent, it does the superlative hardware a disservice.

PCs don't suck. They're inadequate.

Like all software, Qmail can survive only when it keeps up with changing requirements.

Software is getting slower more rapidly than hardware becomes faster.

Simply put, when you have very large pieces of software, most of the tools look at the individual lines of code as text. It is often extremely powerful to look not at individual pieces of code but at a system as a whole.

Most of the effort in the software business goes into the maintenance of code that already exists.

Software as an asset isn't stable over time; it needs to be maintained.

If you look at previous generations, even where they didn't open up power, you look at an early Xbox 360 or early PlayStation 3 games and compare those to the ones that came at the end. The developers are just getting better. So time is far more important than opening up a little bit here or there, though it does all help.

We try to continually push ourselves to do more and more, not just on the hardware side but also in terms of developers' tools so they can take advantage of the hardware that's there, in the best way.

Perhaps you should compile your Perl with long doubles one of these megaseconds.

Software gets slower faster than hardware gets faster.