Iris Classon
Iris Classon - In Love with Code

Stupid Question 54: Performance, when should you care?

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

Performance, when should you care?

Performance seems to be the major subject this week for me as I’ve had daily discussion regarding performance on a new project I’m involved in at work. But, performance seems generally to be a popular subject and many of the questions on the blog have ended up being performance discussions.

‘Stupid’ Question 9: How does reflection affect performance, and should I avoid using it?

‘Stupid’ Question 21: Is there a performance win with ‘as’ casting, and if so – does it matter?

So I have a biggie to ask. When should a programmer care about performance?

I tend to choose what I consider to be performance wise better if the amount of labor and memory footprint involved is the same while trying to keep down the number of dependencies for the

project. I do the basic stuff in regards to performance, but it isn’t a deciding factor most of the time (I’m not talking about database performance here, that is another story). If I know performance can be a big time issue for an application, I spend more time on that early on, but I do tend to tweak later if it an issue as I learned that you shouldn’t optimize early.

BUT, is that right? Do you optimize early, or tweak later?


Leave a comment (via email)
9/29/2012 1:40:31 PM
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. reckon performance is a feature, I think it's something we should strive for. 
Petr Šrámek
9/29/2012 2:14:46 PM
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. 
Stefan Didak
9/29/2012 2:30:15 PM
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. 
Iris Classon
9/29/2012 2:40:09 PM
Reply to: Petr Šrámek
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 :) 
Iris Classon
9/29/2012 2:41:04 PM
Reply to: Alastair
Completly agree with the EF comment! 
Iris Classon
9/29/2012 2:42:33 PM
Reply to: Stefan Didak
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 
Steve Greatrex
9/29/2012 3:02:29 PM
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 
Gareth Bradley
9/30/2012 5:38:08 AM
Reply to: Iris Classon
Completely agree which is why Stack's Miniprofiler is a must for any web project. Also check out Dapper, Stack's Micro-ORM. 
2/4/2013 10:47:19 AM
Reply to: Steve Greatrex
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. 

Last modified on 2012-09-28