in reply to Re: As Efficient as Possible
in thread As Efficient as Possible

Knuth also said:

The improvement in speed from Exampe 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" programs.

In established engineering disciplines a 12 % improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering.

Of course I wouldn't bother making such optimizations on a one-shot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"

Replies are listed 'Best First'.
Re^3: As Efficient as Possible
by mr_p (Scribe) on Apr 02, 2010 at 22:22 UTC
    That is why I want to understand what the code is doing before I put it in my code base. but, I still need my code to be as fast as possible.
[reply]

      mr_p:

      but, I still need my code to be as fast as possible.

      No, you really don't. You need it to be fast enough. You can spend incredible amounts of time and energy making things faster, prettier, more elegant, etc. There's no shortage of time sinks (aka rabbit holes) in our profession.

      If your requirements document tells you to "make it as fast as possible", you need to do one of:

      • Ask for a large budget so you can spend time implementing your code in assembler,
      • Learn how to enjoy unpaid overtime, or
      • Ask them to tell you how fast is fast enough.

      Remember, a requirement is testable. A requirement that "it be as fast as possible" isn't a requirement--you can't tell when you've achieved it. A requirement that says "the system must return a response within 500 ms over 90% of the time" is a fine requirement. It's testable, and you'll know when it's time to move to the next item on your to-do list.

      </learned_from_experience>

      ...roboticus

[reply]
        If I could upvote this another ten times it wouldn't be enough.

        It took me a long time to learn this (and I didn't until long after I quit writing assembler for a living). "As fast as possible" is meaningless unless you're in a situation where you can calculate a theoretical maximum speed easily - and I've never had a project where that was possible.

        You may need to make it clear when you ask for the minimum acceptable performance that you're not shooting to perform at that speed, but that you need to know the minimum to decide on a basic approach: you may be able to say unequivocally that the speed isn't obtainable with your current hardware/network/software stack, or that you know that you'll need a distributed architecture to meet the desired performance goals. Without a hard metric, you might make the assumption that a 10-second response time is acceptable, because that's "as fast as possible" on a single laptop machine, when at least sub-second response is required.

        You're asking to avoid a waste of money and time developing an insufficient solution. You may well be able to do a lot better, but you need to know what's necessary.

[reply]

In Section Seekers of Perl Wisdom