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.

Today with the modern hardware and memory coming cheap, how much sense does it make to spend effort to analyze algoriths or data structure complexity?
Wouldn't it be better instead, to focus on clean, maintainable code, readable code than on optimizations for complexity?
Note:I not talking about embedded systems or systems with similar kinds of constraints.

share|improve this question
add comment

6 Answers 6

Look to your requirements. Codify in specific, measurable, objective terms what constitutes acceptable performance so you have a unified view across stakeholders, management and developer. Let this be your guide in application architecture, application and hardware design, function and performance QA as to whether you have hit your mark and where to spend the time to optimize and when to not.

If you ignore performance and it comes back to bite you as an unarticulated requirement important to a key stakeholder then you are sr*wed because its a helluva lot easier to design in performance than it is to tack it on after the fact.

share|improve this answer
add comment

I can't imagine a day when breeders of fine, ever-faster, racehorses will be able to compensate for overweight, ever-fatter, jockeys.

Hardware engineers knock themselves out making finer and finer lithography, faster clocks, levels of caches, multiple CPUs on a chip. Meanwhile the people who make the software those chips have to execute say "Performance - who cares?"

Performance does matter. Slowness is like any other kind of bugs.

You should try not to make them. But you will make them (if you're working) and you should know how to remove them.

Here's my favorite example.

share|improve this answer
add comment

From a user's perspective what matters is reactivity. Having a notebook or a tablet being ready as soon as it is switched on is very important. This is not achieved only with huge CPU frequencies and tiny memory latencies.

If by complecity you mean also algorithmic complexity, the important point is scalability. Hardware performance is a limited solution when your problem is O(exp N).

share|improve this answer
add comment

First, I question the premise of your question. Nobody deliberately performs "optimizations for complexity". Optimizations are performed to beat performance or resource constraints, and complexity is tolerated if it gets the job done. When done well, analysis of algorithms and data structures enables you to recognize redundant information, needless work, and allows you to write simpler, more easily maintainable code, which also happens to perform better.

Second, while more powerful hardware might allow you to solve yesterday's problem in more obvious and straightforward ways, most of us have to move on to newer and harder problems. Your word processor is finally fast enough? Great, now make it work entirely in a scripting language inside a web browser. You want to do a deep indexing of the entire internet every month? Fine. Google could do that ten years ago. Unfortunately, if you want to keep up with Google, you have to increase the number of page you crawl by an order of magnitude every year. It took us ten years to sequence the first copy of the human genome, now we want to be able do it in a day.

As powerful as hardware is getting, the difficulty of the problems we want to tackle is growing even faster.

share|improve this answer
add comment

Today with the modern hardware and memory coming cheap, how much sense does it make to spend effort to analyze algoriths or data structure complexity?

it still makes sense today.

perhaps the best example i can give is that of cpus' growth in numbers (moreso than in frequency). choosing the right algorithms and structures are still important because you still have these physical maximums - a well written program can take a fraction of the cpu time or resources.

one obvious alternative to choosing the right algos/implementations is to use parallel execution (PE). although it is fine in some cases, PE is not always a good solution:

  • it can become very complex to write.
  • it can be very difficult to debug, test, and maintain.
  • while many problems are good candidates for PE, many do not extend into the domain well.

given the effort it takes to implement PE correctly, the right algos and structures are still important and much simpler and powerful solutions for many cases.

so, let's say you have hit that ceiling: would you prefer to retrofit that program for PE, or would you prefer to use (or verify that your program is using) the proper types/algos/implementations?

even if you choose PE, your program will (in the majority of cases) end up consuming more peak/total resources in its execution = =.

Wouldn't it be better instead, to focus on clean, maintainable code, readable code than on optimizations for complexity?

the two can coexist. (although some languages or runtimes can affect this adversely, such that there is less overlap -- the question is language-agnostic)

share|improve this answer
add comment

Yes, it is always recommendable to focus on correctness first, then readability and maintainability, then - if ever - on performance. In the majority of cases nowadays, performance is not a significant constraint.

That said, it is still a best practice to choose your algorithms and data structures correctly. If this means just calling the right kind of standard library sorting method, or using the right type of container for a given usage pattern, that is usually easy to change later. But anytime you need to really implement some kind of nontrivial algorithm, it is well worth thinking about performance requirements in advance. It may be that there aren't much performance requirements, like if a string search algorithm will be called 10 times a day with a few dozen characters of text. Then it obviously isn't worth spending a lot of time researching/designing algorithm options and tuning its performance. However, if it is called thousands of times a day with a million characters each time, the lack of performance by a badly chosen/implemented algorithm may indeed bring your program to a halt.

So you need to look out and identify potential performance hot spots early enough, and design them carefully if there are such hot spots. Do back-of-the-envelope calculations to estimate the performance, throughput, response time etc. during the analysis and design phase. These may help uncover unrealistic expectations / assumptions about the system. Build an end-to-end skeleton of the system as early as possible, then you can conduct some rough measurements (with dummy data, simplistic workflows, whatever) to get a sense of the real vs expected performance. You also need to take into account expected short / long term increase in traffic. A web site may work well initially with 50 users, but it may get into serious trouble when its user base grows to thousands a year later. It is very painful and risky to try to solve performance problems when the system is already fully congested. Very often it is not obvious that the system is getting closer to its point of congestion - its performance may look acceptable all the time, then all of a sudden drops dramatically. If you can't foresee and prevent these problems in due time, you will need to solve them while angry users' calls are flooding the support lines and your boss is breathing into your neck waiting for the instant solution...

share|improve this answer
1  
Database performance is especially critical to consider in design, it is much harder to refactor a database with millions of records. And there are known performanc ekillers in database design that should generally be avoided from the start. –  HLGEM Sep 21 '11 at 13:55
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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