Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
When is optimization not premature and therefore not evil?

Whilst designing my own .Net SQL access library, I found that I want everything thing to run as fast as possible so I tend to look at the fastest ways of doing things. This often gets criticised as pre-mature optimisation when I am just looking for the fastest way of doing something.

My question is there a cross-over between designing for performance and pre-mature optimisation?

share|improve this question
    
the cross-over occurs when the system fails, and you find it was caused by your optimization... –  james Nov 11 '11 at 1:15
1  
Given the incredibly vast number of ".NET SQL Access Libraries" out there, just how sure are you that yours is going to be any faster? Forget premature optimization, I call that reinventing the wheel... –  Aaronaught Nov 11 '11 at 3:31
add comment

marked as duplicate by Karl Bielefeldt, Robert Harvey, Aaronaught, Anna Lear Nov 11 '11 at 4:18

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

I have found the best design optimization is to find the simplest way to do things. Complexity costs in many ways. Most of your library is likely to be lightly used, so having the fastest performance won't be critical. Working correctly is always critical, and much more likely with a simpler design.

Design to interfaces rather than particular implementation. This will allow you to replace the implementation if needed. Once you have the library implemented, you can profile it see if there are areas you can optimize.

Designing for optimization is getting more difficult and error prone. You really need something you can measure. Write the simplest code that works, then optimize.

share|improve this answer
    
In practice, I find "design to interfaces, not an implementation" is well intended but not very helpful. Most library interface design is influenced by the way it's (initially) implemented. Abstractions leak and end up coming back to haunt you. Coming up with a proper interface in the first place will probably make for simple to use and efficient implementations. –  André Caron Nov 11 '11 at 3:13
    
I was thinking internal implementation, rather than external interface. Designing to generalizations (collection) rather than specifics (array) makes later optimization simpler. It also helps decouple the external interface from the internal implementation. –  BillThor Nov 11 '11 at 3:28
    
Your example is (array VS collection) is rather simple compared to real life abstractions. Consider replacing a local implementation with some distributed/remote implementation. You now suddenly have to deal with (much) more types of errors and will suffer huge slowdown if you have a chatty interface. The type of optimizations you can make are inherently limited by the interface you initially came up with. –  André Caron Nov 11 '11 at 3:51
    
Distributed/remote will always be chatty to some extent, and does inject more type of errors. All the more reason to keep the interface as simple as possible. –  BillThor Nov 11 '11 at 4:14
    
+1 I like your first sentence, though nobody intentionally makes things complicated. Take two people, A makes a complex design, and B makes a simple one. Ask them if their design is simple, and both will say Yes. A needs to learn from B, but typically there's no B around, or A doesn't want to learn. This is not a small issue. The difference can be 1-2 orders of magnitude in line-count. –  Mike Dunlavey Nov 11 '11 at 17:00
add comment

I think the best process is to do the foundational work for your SQL database, so that you can easily make it faster, but don't actually do those steps yet. Set up your tables smartly and write any views you need, so that the interaction with .NET's models (I assume you're using MVC) won't change.

Then, when the client, PM or Testers start complaining about performance, you can go save the day with optimization. And keep notes (to yourself, or on the company's wiki) about what optimizations you can do, while you're still thinking about it.

share|improve this answer
add comment

Correctness first, if only to build a good set of unit tests. Optimizing within that framework will likely get the best overall results.

share|improve this answer
    
As an example, DirectX has a reference rasterizer, though the actual impls are optimized for perf. –  Kevin Hsu Nov 11 '11 at 2:39
add comment

In design, concentrate on the algorithm and approach to solving the problem. In implementation, concentrate on the quirks of the language that make something efficient or inefficient.

It's been said many times, but it really is much tougher to change a bad algorithm later on than it is to optimize an implementation of an algorithm.

share|improve this answer
add comment

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