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.
| [reply] [Watch: Dir/Any] |
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] [Watch: Dir/Any] |
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] [Watch: Dir/Any] |
Yes, I should have used the word optimize.
No, I am not having any problems. But the Data is time sensitive data.
| [reply] [Watch: Dir/Any] |