Stupid Question 54: Performance, when should you care?

I think you need to keep it in perspective. In a web app, agonising over whether a linq .foreach is a few ms slower than explicitly using foreach is pointless if you haven't minimised and gzipped your CSS, adding measurable time onto your apps load time.

I've found that by looking to gain performance in my apps, I've learnt so much. e.g. you can either accept Entity Frameworks performance as "that's just how it is", or you can break out a profiler and *really* understand what its doing and where you might be using it incorrectly.

Stackoverflow.com reckon performance is a feature, I think it's something we should strive for. 

Performance is tightly coupled with application design and developer experiences. Bad application design and developer's mistakes are usualy the main reasons for performance degradation.

I think it is important to continuously improve or at least test performance. Developers are writing code against small amount of data and when testing/debugging it looks performance is good, but after data grows application loose its performance very quickly. Performance testing helps to find these performance issues and visualise application flow with costs for each method call.

My answer is: Test application performance continuously each time you made significant change to the application. When you find bottlenecks change your code to improve performance. 

Since my entire 20+ year career has had software performance always at the center of the projects I've been involved in (mostly related to 3D graphics, etc. where squeezing every last bit of performance out of things made a critical difference) it has become more than clear that you *should* care about performance early on in the design and architecture stage, especially if you're developing more than a small application. Mistakes made by not taking performance goals into account, early on, usually lead to a lot of wasted time and cost later on in a project's lifecycle.

Unfortunately, the trend for the past many years in software development appears to be "features first, performance later". Except, without much forethought being given to the *how* of "how to optimize it later". Of course, in a lot of cases that performance "later" turns into "never" as more and more gets built on top of a design that may have required a different approach.

Knowing when and how to approach your code with optimization and performance in mind is a matter of experience and also one where you need to understand things at a granular level as well as understanding the big picture that's at stake. And with every project often being different from the next, there is no one-size-fits-all recipe and what constitutes best practices may also differ from one project to the next. 

I like the part about testing performance after each significant change, makes perfect sense,- and I can imagine it makes it easier to spot the main culprits as they are being introduced :) 

Completly agree with the EF comment! 

The feature first, performance later is what I have heard a lot too. Fortunately I've also been told to make wise choices a long the way - but to what degree and how comes with experience as you said 

Most times I have tried to predict where performance problems are going to show up I've been wrong. In my experience you're better off writing the code, then finding where the problems *actually* are using a profiler.

Whether you choose to do profiling up front or after you start to see performance issues comes down to how important performance is to your application 

Completely agree which is why Stack's Miniprofiler is a must for any web project. Also check out Dapper, Stack's Micro-ORM. 

That methodology only applies to optimizing specific classes/functions/calls.   Unfortunately I often see people taking carte blanche with that sentiment, and not initially considering their software architecture.  So while you could always return later, and optimize specifics, you cannot just "optimize later" efficient  software design.  Basically that statement work perfectly fine for 'micro-optimizations', but it doesn't apply to the initial architecture.