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.

15 Answers
15

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.

This is true for applications, but not for libraries.
–
sbiOct 7 '09 at 14:27

3

sbi: Even for libraries you often don't need the absolute fastest way of doing things. Making your code hugely complicated to make a minimal improvement which doesn't improve the complexity of the operation will often not be worth it. Obviously the wider and more diverse your library's audience, the more important performance is.
–
Jon SkeetOct 7 '09 at 14:50

1

I'd swap "adequate" with "good". Adequate performance is of nearly critical importance. Good performance can almost always be done simply with good design, not micro-optimizations.
–
darronOct 7 '09 at 15:17

1

@sbi: you are right that the game is different for libraries - you don't know how are you going to be hit. But even for libraries I find designing an interface that can be as fast as possible more challenging than the actual implementaiton itself.
–
peterchenOct 8 '09 at 8:13

1

@jon: High Performance != Complexity in most situations. However, what I've found is that a different equation usually works best: Simplicity leads to High Performance leads to Stability leads to Security.
–
NotMeOct 27 '09 at 22:17

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.

I would add that premature optimization will not only cost time, but quite often will also cost code clarity, making code harder to refactor. Then you can end up with problems when trying to optimize the really important parts...
–
krissOct 7 '09 at 14:40

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.

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?

It's more important to get the logic of the program to work right than to make each method as fast as possible. Remember that 80-90% of your code is executed less than 10% of the time, and therefore will not buy you anything if it's optimized.
–
David R TribbleOct 27 '09 at 22:47

"Optimization" doesn't mean "make every method as fast as possible". The most important optimzation actually happen during design. "Make it right, then make it fast" applies to individual methods, not an application as a whole.
–
peterchenAug 24 '10 at 7:26

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.

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)

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.

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).

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).

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.

Actually I think users will notice it if it takes 5th of a second to respond to a button press, especially if they are used to immediate response in similar programs. Perhaps say 0.01 and 0.04 seconds (which is also a factor of 4, but definitely not worth to go crazy over).
–
UncleBensOct 8 '09 at 15:49

@UncleBens: I just tried opening a few dialogs on the Firefox I am seeing this with. I guess opening the options dialog for the first time it took at least 0.2secs for it to pop up after I clicked on the menu item. The same for the bookmark organization dialog. Opening a new tab probably took even 0.5secs. Yes, that's actually noticeable, but these are still "normal" delays which most of us won't even notice in day-to-day interaction with the programs we use. Most applications settle for this as enough and most users don'Ät mind.
–
sbiOct 9 '09 at 8:28

Performance is something to be designed in from the outset, not tacked on at the end. For the past 15 years I have been working in the performance engineering space and the cause of most project failures that I work on is a lack of requirements on performance. A couple of posts have noted "fast enough" as an observation and whether your expectation matches that of your clients, but what about when you have a situation of your client, your architectural team, your platform engineering team, your functional test team, your performance test team and your operations team all have different expectations on performance, none of which have been committed to stone and measured against. Bad Magic to be certain.

Capture those expectations on the part of your clients. Commit them to a specific, objective, measurable requirement that you can evaluate at each stage of production of your software. Expectations may not be uniform, with one section of your app/code needing to be faster than others, nor will each customer have the same expectations on what is considered acceptable. Having this information will force you to confront decisions in the design and implementation that you may have overlooked in the past and it will result in a product which is a better match to your clients expectations.