Is Performance Always Important?

Question

Since I am a Lone Developer, I have to think about every aspect of the systems I am working on. Lately I've been thinking about performance of my two websites, and ways to improve it. Sites like StackOverflow proclaim, "performance is a feature." However, "premature optimization is the root of all evil," and none of my customers have complained yet about the sites' performance.

My question is, is performance always important? Should performance always be a feature?

Note: I don't think this question is the same as this one, as that poster is asking when to consider performance and I am asking if the answer to that question is always, and if so, why. I also don't think this question should be CW, as I believe there is an answer and reasoning for that answer.

Answer 1

Adequate performance is always important.

Absolute fastest possible performance is almost never important.

It's always worth keeping an eye on performance and being aware of anything outrageously non-optimal that you're doing (particularly at a design/architecture level) but that's not the same as micro-optimising every line of code.

Answer 2

Jackson’s Rules of Optimization:

Rule 1. Don’t do it.

Rule 2 (for experts only). Don’t do it yet— that is, not until you have a perfectly clear and unoptimized solution.

—M. A. Jackson

Extracted from Code Complete 2nd edition.

Answer 3

How important performance is depends largely and foremost on what you do.

For example, if you write a library that can be used in any environment, this can hardly ever have too much performance. In some environments, a 10% performance advantage can be a major feature for a library.

If you, OTOH, write an application, there's always a point where it is fast enough. Users won't neither realize nor care whether a button pressed reacts within 0.05 or 0.2 seconds - even though that's a factor of 4.

However, it is always easier to get working code faster, than it is to get fast code working.

Answer 4

Performance != Optimization.

Performance is a feature indeed, but premature optimization will cost you time and will not yield the same result as when you optimize the parts that need optimization. And you can't really know which parts need optimization until you can actually profile something.

Performance is the feature that your clients will not tell you about if it's missing, unless it's really painfully slow and they're forced to use your product. Existing customers may report it in the end, but new customers will simply not bother if the performance is required.

You need to know what performance you need, and formulate it as a requirement. Then, you have to meet your own requirement.

Answer 5

performance is only important to the extent that developing the performance improvement takes less time than the total amount of time that will be saved for the user(s).

the result is that if you're developing something for millions... yeah it's important to save them time. if you're coding up a tool for your own use... it might be more trouble than it's worth to save a minute or even an hour or more.

(this is clearly not a rule set in stone... there are times when performance is truly critical no matter how much development time it takes)

Answer 6

There should be a balance to everything. Cost (or time to develop) vs Performance for instance. More performance = more cost. If a requirement of the system being built is high performance then the cost should not matter, but if cost is a factor then you optimize within reason. After a while, your return on investment suffers in that more performance does not bring in more returns.

Answer 7

The importance of performance is IMHO highly correlated to your problem set. If you are creating a site with an expectation of a heavy load and lot of server side processing, then you might want to put some more time into performance (otherwise your site might end up being unusable). However, for most applications the the time put into optimizing your perfomance on a website is not going to pay off - users won't notice the difference.

So I guess it breaks down to this:

Will users notice the improvements? How does this improvement compare to competing sites?

If users will notice AND the improvement would be enough to differentiate you from the competition - performance is an important feature - otherwise not so much. (To a point - I don't recommend ignoring it entirely - you don't want your site to turtle along after all).

Answer 8

In most applications 90% or more of execution time is spend in 10% or less of the code. Usually there is little use in optimizing other code than these 10%.

Answer 9

Keep performance in mind but given your situation it would be unwise to spend too much time up front on it.

Performance is important but it's often hard to know where your bottleneck will be. Therefore I'd suggest planning to dedicate some time to this feature once you've got something to work with.

Thus you need to set up metrics that are important to your clients and you. Keep and analyse these measurements. Then estimate how long and how much each would take to implement. Now you can aim on getting as much bang for you buck/time.

If it's web it would be wise to note your page size and performance using Firebug + yslow and/or google page speed. Again, know what applies to a small site like yours and things that only apply to yahoo and google.

Answer 10

To give a generalized answer to a general question:

First make it work, then make it right, then make it fast.

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

This puts a more constructive perspective on "premature optimization is the root of all evil".

So to parallel Jon Skeet's answer, adequate performance (as part of making something work, and making it right) is always important. Even then it can often be addressed after other functionality.

Answer 11

That 'root of all evil' quote is almost always misused and misunderstood.

Designing your application to perform well can be mostly be done with just good design. Good design != premature optimization, and it's utterly ridiculous to go off writing crap code and blowing off doing a better job on the design as an 'evil' waste. Now, I'm not specifically talking about you here... but I see people do this a lot.

It usually saves you time to do a good job on the design. If you emphasize that, you'll get better at it... and get faster and faster at writing systems that perform well from the start.

Understanding what kinds of structures and access methods work best in certain situations is key here.

Sure, if you're app becomes truly massive or has insane speed requirements you may find yourself doing tricked out optimizations that make your code uglier or harder to maintain... and it would be wrong to do those things before you need to.

But that is absolutely NOT the same thing as making an effort to understand and use the right algorithms or data patterns or whatever in the first place.

Your users are probably not going to complain about bad performance if it's bearable. They possibly wouldn't even know it could be faster. Reacting to complaints as a primary driver is a bad way to operate. Sure, you need to address complaints you receive... but a lack of them does not mean there isn't a problem. The fact that you are considering improving performance is a bit of an indicator right there. Was it just a whim, or is some part of you telling you it should be better? Why did you consider improving it?

Just don't go crazy doing unnecessary stuff.

Answer 12

No. Fast enough is generally good enough.

It's not necessarily true, however, that your client's ideas about "fast enough" should trump your own. If you think it's fast enough and your client doesn't then yes, you need to accommodate your ideas to theirs. But if you're client thinks it's fast enough and you don't you should seriously consider going with your opinion, no theirs (since you may be more knowledgeable about performance standards in the wider world).

Answer 13

Jon Skeets 'adequate' nails it, with the additional provision that for a library you don't know yet what's adequate, so it's better to err on the safe side.

It is one of the many stakes you must not get wrong, but the quality of your app is largely determined by the weakest link.

Performance is definitely always important in a certain sense - maybe not the one you mean: namely in all phases of development.

In Big O notation, what's inside the parantheses is largely decided by design - both components isolation and data storage. Choice of algorithm will usually only best/worst case behavior (unless you start with decidedly substandard algorithms). Code optimizations will mostly affect the constant factor - which shouldn't be neglected, either.

But that's true for all aspects of code: in any stage, you have a good chance to fail any aspect - stability, maintainability, compatibility etc. Performance needs to be balanced, so that no aspect is left behind.

Answer 14

No. Performance is not important.

Lack of performance is important.