It depends on how you think about performance. Saying "performance is for suckers" is just as bad as saying "performance is everything, always".

Since you can only count on one hand the number of times performance mattered to you, you probably aren't running into the right sort of problems. Consider things like Amazon, Ticketmaster, Google, and so on. Performance certainly matters there. I'm sure you can come up with several more examples. When I was doing physics, I had to slog through huge datasets. Waiting 30 minutes for a report definitely sucked, so performance mattered there too.

I've worked on some systems that had to serve tens of thousands of people all trying to do something at the same time. Performance certainly mattered there. I've also worked on things where I was lucky if one person used it a day, and performance didn't matter there. Often these things are a matter of scale. Indeed, look for people talking about my Mac::PropertyList module. It's acceptable for small file sizes, but gets exponentially slower with the size of the file. Performance is the big thing that people complain about (anyone want to fix that? :) for that module.

The real answer is "Performance might matter depending on what you are doing". It's one more thing on your to-do list, and you have to prioritize it like everything else. However, as you're coding, you want to have performance in mind so you have less stuff to fix later.

Remember that performance just isn't about fast code either. Over slow networks you want to efficiently use your bandwidth. On multi-user systems, you don't want to suck away all of the CPU cycles or memory (okay, maybe you do, but you shouldn't).

Still, working code usually trumps optimization, but that's just an optimization of non-working code. :)

Given that I'm currently spending lots of time on code which is bringing a clients server to its knees, because the original programmers also seemed to feel "performance doesn't matter", I'd have to say no, it isn't overrated. Performance is one valid metric of code quality. Whether it is the most important metric for your code (or a particular area of your code) depends entirely on what you're doing and what your specs are. Perhaps a better rule would be "Performance doesn't matter, except when it does." :-)

I think these questions are often really about solutions that are "efficient" from the standpoint of laziness and impatience, not runtime.

Questions about Perl idioms and some golfing exercises are examples of this kind of thing: "I know this works, but there must be a shorter/easier way".

Somtimes, that happens to be the same thing as efficiency from a machine perspective (e.g. using map and grep instead of looping over things again and again), but it doesn't have to be to still be valuable.

I'd have to agree with xdg on this one and add that I think a lot of users are really asking for the idiomatic way to do things (which is why I like to answer those questions with links to Effective Perl Programming.

-derby

If nothing else, these types of posts are a nice opportunity to say "Why do you care about the speed of the loop or the variable assignment when you're doing IO, recalculating expensive data, or using a wasteful algorithm?" Some optimizations matter more than others.

Regardless of whether performance matters or not I think its bad practice to write inefficient code when its just as easy to write more efficient code. The important part being "just as easy". If its not just as easy then you have to do cost benefit analysis. If it is just as easy why do something inefficient? Code that is sloppy in this way tends to suffer from death by a thousand cuts. Profiling it doesnt help as the slowdown is distributed too widely, so all you are left with is a total rewrite. Which can be very expensive.

There absolutely are times when performance can be a "make or break" metric. You state that you have been "scripting" for 10 years. This is a generalization, I know, but scripting usually means throwing together some tools to make life easier when it comes to repetitive tasks, maybe automating some daily procedures, etc. In these cases, the difference between the job finishing in 0.025 seconds and 0.5 seconds won't make a difference. Here, performance doesn't matter.

On the other hand, in application programming, performance can be the difference between a snappy, responsive system and one that is laggy and sluggish. Imagine a fighting game that took 1 second to translate your inputs into motions on the screen. You would have to predict what the enemy was about to do in order to react before they act.

For a non-game application example of when performance matters (to some), I just finished working on a complete re-write of our data access layer. It has to handle a total volume of 240 requests per second. It was built with the ability to scale with more hardware, but the hardware order was based on very early performance numbers. Later performance tests showed that we would not have enough hardware to support the volume of traffic and we did not have enough time to order more hardware.

After profiling the system, we were able to squeeze out more than 30% speed improvement by tweaking three subroutines. We swapped out Storable::dclone in favor of Clone::clone (which then proved to leak memory like a sieve) and got an easy 10%. Next, we optimized our sort algorithm and picked up about another 10%. Finally, we minutely tweaked a data accessor, speeding it up by about 0.01%. However, since we used strong data encapsulation throughout the system and this data accessor was used for every attribute of every class, this 0.01% in a single method resulted in an overall 10% gain in the system performance.

When all was said and done, we had brought the system well within the range of performance that we needed in order to launch and service the level of traffic we expected.

So, in short, there are times when performance can matter a lot. And trying to eek out that last little drop of performance can result in a massive win for you application. Without that little tweak, you cannot launch because your site could crash under the load; with it, you can launch and continue to grow.

You know, most times they're looking to learn, and not actually trying to make things run faster.

I just realized that I answered without thinking...

Performance might not be the most important of things all the time, but when it is, it *really* is a pain in the ass!

And, curiously, in the project I'm currently involved with, performance *is* a must! I have to execute over a thousand operations per second, and no, it's not being easy, and yes, it is important!

And in this case, yes, anything that can make things faster on my side, *will* be helpful!

OTOH, it's the first time in three years that I've had performance issues.

in the project I'm currently involved with, performance *is* a must! I have to execute over a thousand operations per second, and no, it's not being easy, and yes, it is important!

Is it anything we can help with?

I generally think 'hey, this does work. but my perl skills in this area are AWFUL. i know that this is using a lot more loops and memory than necessary. and i KNOW that there's a better way to do this, because if every application I use had code like this, my computer just wouldn't run. i need to learn the best, most efficient way to perform this task and take that learning into other functions that i program."

Beware of thinking that the most efficient solution is the "best" - often, the best solution may not be the most efficient solution possible, but the cleanest, most maintainable, most flexible, etc...

It's probably bad form to respond to one post twice, but the more I thought about this, the more the argument reminded me of the situation pre-1973 oil crisis, where cars were getting bigger & bigger, and less and less efficient. The solution to the effect of every extra hundredweight of chrome that was added to the outside; was to add more cubic inches to the engine. Petrol was cheap, who cared how much we burnt. Then suddenly petrol wasn't cheap anymore, and those tiny, clunky looking, economic Honda Civics and Nissan Sunnys that everyone had been laughing at, took over the world.

Unfortunately, the lessons of the early '70s have been forgotten, and here we are again with petrol prices going through the roof. Except that this time it's not because a few Sheiks in power decide to raise the prices, but because we're using it up at such a rate, it's running out.

Application code should programmed to be as efficient as is required by it's users--commensurate with correctness and maintainability. If the users are happy with it's performance, there is little mileage in improving performance further.

Library code should be code to be as efficient as is economically possible--commensurate with correctness and maintainability. The author of library code never knows what the demands and requirements of the applications that will use it will be. The more efficient it is (both cycles and memory), the less likely the application programmer using it is going to have to take extraordinary measures (like seeking micro-optimisations), in order to satisfy the requirements of it's users.

I wonder how long it will be before the Moore's Law bubble bursts?

If it takes less than 1/2 a second it's fast enough. If it takes more than 10 seconds it is too slow. Within the realm of general computing tasks it doesn't matter what it is. Doesn't mean you can speed it up of course - some things just take the time they are going take. But if you are waiting for it, it's too slow and otherwise it's fast enough. :)

Used to be that computers were slower than they are now and to get acceptable performance you had to do tricky stuff of many more types of it than you do now. Some people are still stuck in that pattern of thought.

As others have said or implied in this thread, there is great virtue in providing an idiomatic solution to a common problam so that a "nearly best" solution just flows off the finger tips. If performance is measured in "time to solution", then time writing the code to find the solution is a component too - lazyness counts for a lot and idiomatic code is very often a nice compromise between programmer and execution performance.

Keep those performance questions coming.

If it takes less than 1/2 a second it's fast enough. If it takes more than 10 seconds it is too slow. Within the realm of general computing tasks it doesn't matter what it is.

Maybe I'm misreading your point here, but it very much matters what it is. If your processing data that arrives daily, 10 seconds is not too slow. If your processing data that is arriving every 1/4 of a second, 1/2 second isn't fast enough.

Without knowing what it is, its impossible to say whether performance is a problem or not.

What many people are implying but not quite stating is this: even a small gain in performance is exceedingly important if it is likely to aggregate.

Imagine you have a process you run 100 times a day at 2 seconds each. If you manage a 5% improvement, you only save 10 seconds a day. Probably not worth it.

Now imagine the same script needs to run 45000 times in a day... whoops, there aren't 90000 seconds in a day, so you'll have to speed it up somehow. A 5% efficiency improvement, though, means you'll finish on time (23.75 hours of processing for 45000 transactions). Performance certainly mattered here.

The only remaining question, then, is whether you anticipate given code will run often enough that a small gain in performance will aggregate into big gains overall -- and don't forget to plan for the future!

If someone totally new to programming were to ask me for advice, I think I'd say "performance is for suckers."

Let me offer a variation: "Make sure you understand what's important to the people who are paying you, and don't sucker yourself into spending their time working on things that aren't important to them. That's what your own time is for."

This is the best reply to this thread I've read yet! :-)

What does everyone think about that? Am I totally crazy?

1. Make it run
2. Make it run fast.

That said, there are some problems where the scale is such that you can't have too much performance. As an example, think about processing the Apache logs for the likes of Yahoo or Google or Amazon. If they aren't (individually) producing 100's of gigabytes of logs per day, I'd be most highly supprised. Problems on this size *are* worth tweaking every bit of performance -- a 0.001% reduction in the amount of time it takes to process 1000 log messages translates at that scale to over an hour reduction in the process.

Once you have something that "works", release that to the User and let them work with it for a while. They are the arbiters of whether the solution is 'fast enough'. If they are happy with it, you are done; even if you could coax an extra 20% reduction ibn the run time if you only ....

A couple of points:

• happiness isn't binary; users might be mildly happy with adequate performance, but estatic with fast performance, or grudgingly accepting of poor performance
• User acceptance is important; change is bad! Often, when you're redesigning the entire system for performance, you can make the system much faster and more consistant if you revise the end-user paradigm. You can't do that if you hand off the first system to the end users: you'll have user acceptance issues like crazy the minute you try to change anything. Users don't like wasting time on training, and training costs are real costs. The minute something hits production, remember, you'll have to support it for years, so choose carefully!
• Management hates testing time. If you want to rebuild and retest a system to do the same thing as an old system because you didn't build it fast enough in the first place, they're going to get angry with you. Given that testing takes twice as long as development, you're going to waste a *lot* of time if you don't develop the system right the first time...

These points aren't irrefutable; there are often exceptions, and they're mostly grounded in business culture, which varies from place to place. But in my experiences, those are the real world factors that get in the way of the rosy, ivory tower view of how software gets engineered; expecting things to be otherwise leads to bitter disappointment.

It depends on what you mean by performance. If you mean micro-optimisations like converting hash access to array access then these can matter somewhat if you are trying to handle large volumes of data or requests but the benefits tend to linear in the amount of data your process. That is by making 1 cycle of processing 10% cheaper, you knock at most 10% of the whole process.

On the other hand there are optimisations like using quicksort instead of bubblesort or using a heap for a priority queue rather than an array or a linked list. These are the sort of optimisations that change your program from take n^2 second to n*log(n) seconds. This can be the difference between "it finishes after an hour" and "I left it running all weekend and it's still not finished". These days performance tends to only matter for scaling up. We tend to have plenty of memory and things tend to finish faster than we can notice so

What's worse, sometimes you write a nice, pretty, and slow implemenation that actually incurs a business cost, and then you have to do more work (or buy new hardware) to fix it.

By then, the whole thing is probably into production, so rewriting the whole thing will be frowned upon, especially when you just wrote it in the first place. In general, due to business politics, you get one chance to get a system right every five to ten years; after that, you have to support it.

Do it right the first time. Otherwise, you'll end up doing it right five years from now... and be yelled at for five years for writing a slow, clunky system that you're not allowed to fix. :-(

I wonder if you would be able to be so complacent about the performance of your Perl scripts if the writers and maintainers of Perl itself had adopted your "performance is for suckers." attitude?

How much slower could your scripts run and still be within the realms of acceptability to your users?

See, there’s a difference. perl is invoked hundreds of millions of times every day. It pays to microoptimise that. I doubt the scripts the OP writes get that sort of work-over.

It’s always a matter of tradeoffs and diminishing returns in various forms of expenditure.

Personally, I always try to write code that doesn’t do unnecessary work; this is mostly a question of cultivating algorithmic sensitivity and understanding how things work under the hood. But I only actually start worrying about performance when the performance gets worrisome.

Makeshifts last the longest.

Then the dataset grew, the requirements changed, and the thing that once worked just fine required 20 minutes or more to run. 30 sales lost per day was not acceptable to the client. Suddenly, runtime mattered a lot.

Like so much of life, the correct answer is situationally dependent. Performance may or may not matter, but you cannot issue one statement and expect it to fit all cases.

As someone else said, first make it run, then make it run fast. To that I would add, "... if fast is necessary".

Yes, it is. I'm guilty in that too.

Perhaps you've spent the last ten years scripting. I, however, have spent it writing applications. And boy do application users whinge when things run too slowly.

Yes they do.

They also whinge when the functionality they need isn't in place because the developers are having to deal with this god awful tightly coupled unmaintainable mess that's been produced in the name of efficiency.

In my years of writing applications I have had far more problems due to programmers trying to be clever in the name of efficiency than I have with programmers not being efficient enough.

Other measures of performance people should be more concerned about:

• Programmer's cost vs. output (quality, quantity, speed) vs. happiness (sustainability, burnout) performance (relevant to why we use Perl and not assembly)
• Latency and response (perceived performance very critical in the webapp/GUI world)
• load (running the program once is OK, but 100 times on the same machine? relates to both latency and throughput)
• disk usage (important in some specialized fields, for example high end databases)
• throughput (the "regular" performance, really only worth it when it comes to batch processing *HUGE* amounts of data. why you might want to use assembly and not Perl)
• maintainability, readability, debuggability - think of this as robustness performance - how your app performs in the course of it's entire life, with respect to changing priorities/requirements/staff.
• ...

Also, wrt throughput, remember that typically when someone runs a long program they tend to run it 10 times before on smaller data, just to make sure it works like they expected. I tend to try to make sure that I can slice that chunk of time by giving nice progress reports, and decent defaults/warnings/hooks, thus usually halving the truly total time, instead of making sure i can fudge data a into data b in the minimum number of opcodes.

Anyway, my point is: Balance is everything.