0

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?

Improve this question
2
  • the cross-over occurs when the system fails, and you find it was caused by your optimization...
    – jqa
    Commented Nov 11, 2011 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
    Commented Nov 11, 2011 at 3:31

4 Answers 4

Reset to default
1

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.

Improve this answer
5
  • 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
    Commented Nov 11, 2011 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
    Commented Nov 11, 2011 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
    Commented Nov 11, 2011 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
    Commented Nov 11, 2011 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
    Commented Nov 11, 2011 at 17:00
0

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.

Improve this answer
0

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

Improve this answer
1
  • As an example, DirectX has a reference rasterizer, though the actual impls are optimized for perf.
    – Kevin Hsu
    Commented Nov 11, 2011 at 2:39
0

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.

Improve this answer

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