What's more important: To write programs fast or to write fast programs? According to: http://math.stackexchange.com/questions/17478/how-quickly-with-better-tool it is better to write fast programs, but I wanted to ask this Q here to get the general gist of what you're thinking on this subject. Of course I'm taking as a given that all programs have to be correct etc. etc.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
closed as not constructive by TheLQ, NickC, Mark Trapp Jul 1 '11 at 7:40
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
"Make it Work, Make it Right, Make it Fast" (in that order) Both are important, but realistically, you will need to compromise between them:
|
|||||||||||||
|
|
Depends strongly on what your boss prefers. Also, humans are notoriously bad at guessing where the non-fast code is, so it is better to write correct code with reasonable performance, and then have a closer look at the 5 percent then found not performing reasonably. |
|||
|
|
|
If you don't immediately and explicitly need high performance of your programs, don't waste time here. That's simply another conclusion coming of the commonly known KISS and YAGNI principles. For most situations (by numbers) the difference in a few milliseconds won't make a difference. Whether a program performs a user-invoked action in 2.64 or in 2.68 seconds is of no importance. For database-driven and web applications milliseconds matter even less since there are almost always significant delays. Another aspect to remember, is that it is considered bad for usability if a program responds below certain threshold, the user must be able to "watch" the program as it executes. |
|||
|
|
|
If you're battling other companies to release the first program on a new market, I would recommend you release it as fast as possible and don't bother making it fast. In fact, you don't really need the best functionality as long as you iterate and release often. |
|||
|
|
|
It depends on the purpose of the program. If you are writing a library, it's useful to write a fast program because you have no idea where your library will be used in. For normal applications, it would be more useful to write a program that is fast enough fast. So my answer is that it depends. |
|||
|
|
|
What is the cost of a CPU hour? A byte-in-RAM hour? A programmer hour? Given that (and, possibly, "byte-on-disk hour" and a couple of other measurements), you could, in theory, decide exactly where the cut-off is for various possible scenarios. Unless you're into massively parallel computing, I'd suspect that "programmer hours" is more expensive than "machine hours". |
|||
|
|
The formula in the answer over there is interesting, basically it says if the job you're writing the program for takes more than 18 hours, then it's better spend more time writing the "fast" version than to writer the "slow" version. Which is interesting in the theory. However, it makes a couple of assumptions which I think invalidates the argument in practice. The first is that the job is something that you've never had to do before. Most software is written in order to automate an already existing process. For example, you might write software to help you manage client accounts, or to book plane tickets or something: before the software existed, you still had to "do the job" but it was a manual process. In that case, there is still benefit to the fast-to-write, slow-to-execute code, because it's still faster than the manual process. Every time you run the slow-to-execute program, you're still saving yourself money over the manual process. The second assumption is that there is no opportunity cost in spending time to make it run faster. That is, you might spend 1 hour writing the slow version, or 10 hours writing the fast version. That's 9 hours where you could have been doing something else. Now, we can't say what those 9 hours could have been used for: maybe you could have made 9 other things run twice as fast. So the choice is 10 hours making one thing four times faster, or 10 hours making 10 things twice as fast. Or maybe you just spend those 9 extra hours on Facebook... Finally, it's also quite rare in practice that the trade-off is as simple as "spend longer to make it faster". You usually have to trade off other qualities in order to make your code faster. For example, it might become harder to maintain, or is not as flexible (so if the customer wants a new feature, all of a sudden you can't use your super-optimized code and have to throw it all out). Maybe the faster version is only faster under certain conditions, and if those conditions don't match up then it runs even slower. In general, there is usually much more to the equation than just "do I spend longer making my program run faster?" |
|||||||
|
|
In my opinion it depends on the situation
but ill prefer write fast program |
|||
|
|
|
It depends on who the user of the program is. If it's a program with a GUI that you expect to receive user feedback on, then develop it fast so that user feedback is collected ASAP. It's difficult, if not impossible, to accurately gauge what the users of a GUI application want prior to development. If it's a server-side program that will interface with other services (i.e. SOAP, XML-RPC, REST), then development speed it less important. It's been my experience that with server-side programs their correctness and performance matter more. Server-side programs can sometimes be difficult to debug, so getting it right the first time matters. This often means writing a lot of unit-tests to verify program correctness. |
|||
|
|
|
Speed is relative to a user's perception. Improving a 5 sec process to 4 seconds isn't noticable to those who don't carry a stop watch. If I write a process that runs during off hours, why would I need to increase the speed if it is done in time. The sooner you get a product infront of users, the faster you get feedback on their expectations. Many businesses just can't wait for faster applications and very few are in situations where speed counts. If speed mattered, internet apps wouldn't have become so popular. We sacrificed speed for a host of conveniences to the users and developers. To answer the question: speed matters some of the time. |
|||
|
|
