Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Mon Jun 3 21:53:34 PDT 2013


On 4 June 2013 14:23, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>wrote:

> On 6/4/13 12:13 AM, Manu wrote:
>
>> The fact that virtual is a one way trip, and it can not safely be
>> revoked later and therefore a very dangerous choice as the default is a
>> maintenance problem.
>>
>
> Certainly you're omitting a good part of the setup, which I assume has to
> do with binary compatibility and prebuilt binaries. In other setups, final
> is the one-way trip by definition - it restricts potential flexibility.


I don't buy the flexibility argument as a plus. I think that's a mistake,
but I granted that's a value judgement.

 The fact that I'm yet to witness a single programmer ever declare their
>> final methods at the time of authoring is a problem.
>>
>
> Too narrow a social circle? :o)


Well let's consider Steven's example from a short while ago. He didn't
write final anywhere, and at some later time, retro-actively introduced it
because he realised it was a performance burden.
At which point, refer to point #1. He was lucky that he was able to do this
without any complaints from customers.
But it's a breaking change to the API no matter which way you slice it, and
I suspect this will be the prevalent pattern.
So it basically commits to a future of endless breaking changes when
someone wants to tighten up the performance of their library, and typically
only after it has had time in the wild to identify the problem.


 The fact that many useful libraries might become inaccessible to what
>> I'm sure is not an insignificant niche of potential D users is a problem.
>>
>
> Not getting this. I dare believe that a competent library designer would
> be able to choose which functions ought to be overridden and which
> oughtn't. The moment the issue gets raised, the way the default goes is
> irrelevant. (But maybe I'm just not getting this.)


Situation: I have a closed source library I want to use. I test and find
that it doesn't meet our requirements for some trivial matter like
performance (super common, I assure you).
The author is not responsive, possibly because it would be a potentially
breaking change to all the other customers of the library, I've now wasted
a month of production time in discussions in an already tight schedule, and
I begin the process of re-inventing the wheel.
I've spent 10 years repeating this pattern. It will still be present with
final-by-default, but it will be MUCH WORSE with virtual-by-default. I
don't want to step backwards on this front.

Even with C++ final-by-default, we've had to avoid libraries because C++
developers can be virtual-tastic sticking it on everything.
D will magnify this issue immensely with virtual-by-default. At least in
C++, nobody ever writes virtual on trivial accessors.
virtual accessors/properties will likely eliminate many more libraries on
the spot for being used in high frequency situations.

Again, refer to Steven's pattern. Methods will almost always be virtual in
D (because the author didn't care), until someone flags the issue years
later... and then can it realistically be changed? Is it too late?
Conversely, if virtual needs to be added at a later time, there are no such
nasty side effects. It is always safe.

 And I argue the subjective opinion, that code can't possibly be correct
>> if the author never considered how the API may be used outside his
>> design premise, and can never test it.
>>
>
> I think you are wrong in thinking traditional procedural testing methods
> should apply to OOP designs. I can see how that fails indeed.


Can you elaborate?
And can you convince me that an author of a class that can be
transformed/abused in any way that he may have never even considered, can
realistically reason about how to design his class well without being
explicit about virtuals?

I've made the point before that the sorts of super-polymorphic classes that
might have mostly-virtuals are foundational classes, written once and used
many times.
These are not the classes that programmers sitting at their desk are
banging out day after day. This are not the common case. Such a carefully
designed and engineered base class can afford a moment to type 'virtual:'
at the top.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130604/8335bead/attachment-0001.html>


More information about the Digitalmars-d mailing list