8

I work in a small sized software/web development company.

I have gotten into the habit of optimizing prematurely, I know it is evil and promotes bad code, but I have been working at this firm for a long while and I have deemed this as a necessary evil.

It has never caused me an issue so far in the past, but it might if I get partners or a successor.

Should I change my current practice now to prepare for that case, or should I not worry about it?

Improve this question
11
  • 16
    Are you optimizing prematurely or are you just a good programmer?
    – Jeremy
    Commented Feb 8, 2011 at 2:45
  • 8
    What's an example of when you optimized something prematurely?
    – rreeverb
    Commented Feb 8, 2011 at 3:24
  • 5
    Did I miss the long-winded speech?
    – Marcie
    Commented Feb 8, 2011 at 16:17
  • 3
    See this answer.
    – Mike Dunlavey
    Commented May 11, 2011 at 12:58
  • 8
    The word "premature" carries bad connotations, and the definition means "too early", so, yes, if it's premature, then it is bad by the definition of "premature". If you optimize early, but have compelling reasons for doing so, it is not premature. Perhaps your question would be better phrased as "When is it appropriate to optimize early?"
    – Mike Samuel
    Commented May 11, 2011 at 17:14

8 Answers 8

Reset to default
14

IMO, 'optimising prematurely' is only bad if reduces readability. Programming tends to be a write-once read-many activity, and if your optimisations make the code significantly harder to understand then I would be concerned.

I would take a guess that the effort required to refactor your code would not be worth the benefits (in business terms), but its amazing what the odd comment does to enhance code clarity. This is especially true for 'unusual' code (i.e. the optimisations your are concerned about).

Improve this answer
6
  • Well I'd be the only person viewing the actual code, just my concern was if I get replaces or another team member it could cause issues.
    – MattyD
    Commented Feb 8, 2011 at 3:33
  • If you are concerned, I'd go through parts of the code you know to be a bit hairy and add some explanatory comments. Not line-by-line 'create a new object' or 'add 4 to x' comments, but a few paragraphs to give an overview of what's happening.
    – GavinH
    Commented Feb 8, 2011 at 3:43
  • That sounds like a good plan! Hopefully I can get back to the roots and stop being a tool ;)
    – MattyD
    Commented Feb 8, 2011 at 3:45
  • If only there was somewhere you could post some examples and get feedback on how readable or otherwise they actually are... codereview.stackexchange.com
    – glenatron
    Commented Feb 8, 2011 at 11:36
  • 2
    optimizing premature is not only bad if it reduces readability. If I spend two days optimizing an obscure part of my program that is hardly ever used, I've wasted my employer's money. You should always profile to figure out where you need to optimize before you optimize.
    – Malfist
    Commented May 11, 2011 at 13:17
12

Although this question has been answered IMO biggest drawback of premature optimization is the time wasted both initially while optimizing without having the necessary performance information as well as (frequent) rewrites because while focusing on optimization the implementation has gone askew. Again IMO I think it is not a good programming practice.

Improve this answer
2
  • 1
    +1 - don't waste time optimizing unless you are absolutely sure it's necessary!
    – ozz
    Commented Feb 8, 2011 at 9:07
  • 4
    +1 don't waste time optimizing unless you know you are -really- optimizing. If it's not a good, solid optimization, then it may be counter-productive. Focus on writing good code first.
    – Bill
    Commented Feb 8, 2011 at 17:48
3

Sounds like what you call optimising is what I call cutting corners.

If it truly is optimising, then there is only one answer: document it well.

If it is cutting corners, then it really is up to you to see where the benefits outweigh the risks, be prepared to justify, or change that habit if it is not justifiable (in your own view... until you get involved with others and then use peer review as your measuring stick).

Improve this answer
1
  • 1
    hmm... yeah, I don't understand what optimizing has to do with him being lazy and "I'd like to do best practices but don't see the point...".
    – ozz
    Commented Feb 8, 2011 at 9:09
2

When talking about microoptimizations, looking to squeeze every last nanosecond out of that for loop, it often isn't worth your time. When working on a web/database application, make sure your database interactions are more or less optimal, but more importantly, make sure they'll scale. Unless you're working on very high-performance code, scientific data processing or some such thing, other procedural optimizations won't help you much.

Improve this answer
1

Optimizing without profiling is always wasted time & energy. Shooting in the dark. Voodoo stuff. Bad.

Before optimizing do profile and/or analyze to make sure that:

  • You do actually have a performance problem

and

  • You know where the bottleneck is

Don't try guessing. Measure twice, cut once.

And after optimizing, profile again to make sure you solved the problem.

Improve this answer
5
  • Well, I once had this screen someone else wrote that tool about 60 seconds to open. I optimized it so it took less than 2 seconds. I didn't need to profile anything.
    – Scott Whitlock
    Commented Feb 8, 2011 at 17:09
  • @Scott Whitlock: Good for you :) I did mention "or analyze". At least you took some measurements before and after to verify results, which is good. And if you knew (?) from previous experience (on that software/screen) that 60 seconds is way too much, you did knew that a) you do have a problem and b) where it roughly is.
    – Maglob
    Commented Feb 8, 2011 at 17:24
  • 3
    This is absolutely wrong. Profiling is a great tool, but it's entirely reasonable to say that you know what the critical path of your code is going to be, and to optimize that to an extent as you are developing. Granted, at first pass this should be mostly relegated to design and algorithmic concerns, and the low-hanging fruit of implementation level optimizations, but it's quite naive to just go about writing without a care in the world for performance until after you start profiling.
    – Cercerilla
    Commented Feb 8, 2011 at 19:05
  • @CodeninjaTim, I don't think he said, "pay no mind to performance while writing code." He said to profile before optimizing. There is a difference. For example, I know not to write a loop that does everything twice, but is that optimizing if I write it so it doesn't? I don't think so.
    – Malfist
    Commented May 11, 2011 at 13:20
  • 1
    @Malfist, but where do you draw the line? The whole "profile before optimizing" mantra seems tautological when you simply stop considering anything you'd do before profiling to be optimization.
    – Cercerilla
    Commented May 11, 2011 at 14:41
0

In small shops many developers are also the designers and analysts. When you have a bigger picture (did I just say that?) of the problem, we are more likely to plan ahead. If it performs poorly, it's a direct reflection on you since you're the only programmer.

Narrowing your estimation time can be a little trick to cause you to speed up and stop any unnecessary development. Any kick in the pants will do.

Improve this answer
0

To Your current state

It always worked for You to do it? "If it is not broken, don't fix it" is another golden rule which I should stick to more. It caused me lot of headache when I did not stick to it. It can never cause You a problem, but who knows.

As has been said before "do the simplest thing that could possibly work". I found Pike rules on programming to be very enlightening.

What to consider

I assume You mean mostly speed optimization. Because there is also optimization for readability, size ...

Premature optimization is always bad, because:

  • It takes time to optimize. You might have spend this time by making something better; for example, calling Your girlfriend;).
  • Optimization usually means making things more concrete.
  • It will most likely be unreadable to other programmers. Every programmer should know simple algorithms so if there is something more complex he will waste time puzzing on what it means; he will be thninking low level, parsing more information and quite likely making errors in understanding Your optimized code.
  • It has been said by Donnald Knuth, which is the authority for programming and if he claims something is some way it is almost certainly so.
  • You have to measure first where is Your system slow and THEN optimize. Not the other way around. For example Quake engine used string compare O(N) to lookup variables instead of hashing O(1), it used scripted language Quake C which took about 10 percent of it's performance and "famous" PVS is simple hashing O(1) with simple compression (visibility is precomputed, each section of world to each section therefore what objects are visible is obtained trough a hash map lookup and since such information is huge in memory it is compressed). Michael Abrash's Graphics Programming Black Book is full of "measure first"" examples and examples where he was wrong estimating what was problem (chapter 17

But premature optimization is not always bad, because:

  • There cases when, by optimizing, You can see better solution. But is is about more about a chance.

So You have to weight pros and cons of doing premature optimizations.

I think that, because we are all people You just have to burn Yourself few times with premature optimizations to stop using them.

Improve this answer
0

The Knuth quote is in a context where it is expected you write as good code as you can in the first place. The optimization part is where you give in on the good code to get an expected performance boost, by writing less clear code or do smart tricks.

This is usually not a good idea, as you rarely know when it will be needed ahead of time - this is the job of the profiler to tell you - so you end up with sub-optimal code without any benefit.

Note, that "as good code as you can" may be doing a normal amount of trickery which in your experience is necessary anyway, but then it is your job to document these things well for future you's.

It is my experience that compilers do a very good job of creating good code for good, simple code, but may be confused by smart code. Smart code has its place to work around issues (runtime or compiler wise) but do not overdo it.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.