<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 March 2014 15:51, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'd like to address, in general, the issue of, what I term, "performance by default" which is part of the argument for final by default.<br>

<br>
C, C++, and D are billed as languages for writing high performance apps. And this is true. What is not true, or at least has not been true in my experience, is that an application is high performance merely because it is written in C, C++ or D.<br>

<br>
Let me emphasize, code is not fast just because it is written using a high performance language.<br>
<br>
High performance code does not happen by accident, it has to be intentionally written that way. Furthermore, I can pretty much guarantee you that if an application has never been profiled, its speed can be doubled by using a profiler. And if you really, really want high performance code, you're going to have to spend time looking at the assembler dumps of the code and tweaking the source code to get things right.<br>

<br>
High performance code is not going to emanate from those programmers who are not skilled in the art, it is not going to happen by accident, it is not going to happen by following best practices, it is not going to happen just because you're writing in C/C++/D.<br>

<br>
D certainly provides what is necessary to write code that blows away conventional C or C++ code.<br></blockquote><div><br></div><div>But you understand the danger in creating a situation where experts can't optimise their code even if they want to; if at some later time it becomes an issue, or some new customer comes along with more stringent requirements.<br>
</div><div>These are not unrealistic hypothetical scenarios. Libraries exist, and they have customers by definition. Requirements change over time. Defaulting to an inflexible position is dangerous.</div><div><br></div><div>
There's another programming principle; beware of early-optimisation. Many people swear by this. These 2 situations are at odds.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

It reminds me of when I worked in a machine shop in college. I'd toil for hours cutting parts, and the parts were not round, the holes were off center, heck, the surfaces weren't that smooth. There was an older machinist there who'd take pity on me. He'd look at what I was doing, cluck cluck, he'd touch the bit with a grinder, he'd tweak the feed speed, he'd make arcane adjustments to the machine tool, and out would come perfect parts. I am an awe to this day of his skill - I still don't know how he did it. The point is, he and I were using the same tools. He knew how to make them sing, I didn't.<br>

<br>
I still cannot drill a goddam hole and get it where I measured it should be.<br>
</blockquote></div><br></div></div>