Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Performance, Abstraction and HOP

by Ovid (Cardinal)
on Aug 31, 2005 at 21:46 UTC ( #488239=note: print w/ replies, xml ) Need Help??


in reply to Performance, Abstraction and HOP

I think you'll agree with what I'm about to say, but I think it's an important point to reiterate.

You wrote: ...performance is important, and it is always one of the most important measurement of the quality of your application.

In a paper defending the virtues of goto, Knuth wrote about looking forward to the day when computers were fast enough that performance is no longer such a critical concern. Interestingly, his comments relate to yours in two different ways. He was making it clear that performance a necessary consideration but, more importantly, he was directly addressing the "never use goto" dogma that had arisen. (As a third point of relevance, I got that link from the HOP mailing list).

The problem with the dogma was fairly simple: by using "always" as the criteria, one was sometimes forced to go to extreme lengths to avoid goto and this could cause performance issues. In your case, you state that performance is always one of the most important considerations. I tend to disagree.

Admittedly, there are certain classes of problems for which performance issues must be addressed up front. Ray tracing programs are rarely written in Perl. In this case, a better solution that figuring out how to improve the performance of your favorite tool is to figure out the most appropriate tool for the job. C or C++ are going to be big wins here.

If I am forced to pick a "most important" measure of quality, I would argue for program completeness and correctness. In other words, the program should correctly do everything that it is supposed to do and do nothing it's not required to do. Once you have correctness and completeness down then, if performance is still an issue, profiling should be considered.

Sometimes performance is gained by coupling things that shouldn't be coupled, denormalizing the database or writing an obscure algorithm. However, if someone is doing that up front I'm going to be pretty unhappy if they've tripled the speed of a function that only uses two percent of the total program run time. Frequently when programmers guess where the performance problems will be they guess wrong. Thus, by worrying about performance before we worry about correctness and completeness, we're more liable to build overly complicated and confusing code. What's worse, that confusing code is less likely to benefit our overall performance.

Performance is often important, but it should rarely be the first consideration. If we avoid useful (a carefully chosen word) abstractions out of fear they will slow things down, we're hurting our ability to write correct and complete code. Focus on performance after you know the code is right.

Cheers,
Ovid

New address of my CGI Course.


Comment on Re: Performance, Abstraction and HOP
Re^2: Performance, Abstraction and HOP
by Anonymous Monk on Sep 01, 2005 at 22:02 UTC
    I agree in principle with most of what you've said, but there are a few qualifiers that I would add:

    If I am forced to pick a "most important" measure of quality, I would argue for program completeness and correctness. In other words, the program should correctly do everything that it is supposed to do and do nothing it's not required to do. Once you have correctness and completeness down then, if performance is still an issue, profiling should be considered.

    In some cases, such as real time programming, responsiveness is completeness. It's no help to have the brakes activate with the optimal number of newtons of force after the car has already hit the tree. It's better to have a "wrong" solution that applies the brakes a bit too hard or too soft than too late.

    Focus on performance after you know the code is right.

    In practice, this is easier said than done. What if the fundamental data structures and design decisions are the inefficient part? If the design gets too abstract, this can happen. I've seen it happen many times in the past.

    Whenever you need to change the fundamental assumptions of a program, you're either looking a massive refactoring project, or possibly even a total rewrite. Just try telling management that the expensive new program you spent months writing for them is too slow and needs to be totally redone from scratch. That's pink slip territory for a lot of us.

    Sometimes, it's better to design efficiently in the first place, and worry about abstraction later. It's nice to solve problems that you might not have, but a clean design that solves your current problem might well be smarter and cheaper in the long run.
    --
    Ytrew Q. Uiop

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://488239]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2014-08-20 09:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (110 votes), past polls