On 3/14/2014 5:06 AM, Manu wrote:
In my experience, API layout is the sort of performance detail that library
authors are much more likely to carefully consider and get right. It's higher
level, easier to understand, and affects all architectures equally.
It's also something that they teach in uni. People write books about that sort
of thing.
Not to say there aren't terrible API designs out there, but D doesn't make
terrible-api-design-by-default a feature.
Stuff like virtual is the sort of thing that only gets addressed when it is
reported by a user that cares, and library authors are terribly reluctant to
implement a breaking change because some user reported it. I know this from
experience.
I can say with confidence, poor API design has caused me less problems than
virtual in my career.
Can you honestly tell me that you truly believe that library authors will
consider, as a matter of common sense, the implications of virtual (the silent
default state) in their api?
Do you truly believe that I'm making a big deal out of nothing; that I will
never actually, in practise, encounter trivial accessors and properties that
can't inline appearing in my hot loops, or other related issues.
Inline-ability is a very strong API level performance influence, especially in a
language with properties.
Most programmers are not low-level experts, they don't know how to protect
themselves from this sort of thing. Honestly, almost everyone will just stick
with the default.
I find it incongruous to take the position that programmers know all about
layout for performance and nothing about function indirection? It leads me to
believe that these programmers never once tested their code for performance.
I know what I'm doing, and even I, when I don't test things, always make some
innocuous mistake that eviscerates performance. I find it very hard to believe
that final-by-default will fix untested code.
And the library APIs still are fixable. Consider:
class C {
void foo() { ... }
}
and foo() needs to be final for performance, but we don't want to break existing
users:
class C {
void foo() { foo2(); }
final void foo2() { ... }
}
