Slow performance compared to C++, ideas?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jun 3 22:58:37 PDT 2013


On 6/4/13 1:16 AM, Manu wrote:
> But unlike the first situation, this is a breaking change. If you are
> not the only user of your library, then this can't be done safely.

Same fallacy all over again, for the third time in this thread. You keep 
on going about "breaking change" without recognizing that the now broken 
code was happily taking advantage of the very flexibility that you argue 
was useless and needed fixing.

This is exactly the kind of argumentation that I disagree with, 
philosophically. Instead of carefully pondering the goods and the bads 
in a complex web of tradeoffs, it just clumsily gropes for the desired 
conclusion in ignorance of all that doesn't fit.

> If you write code like that, then write 'virtual:', it doesn't hurt
> anyone else. The converse is not true.

Fourth.

>     I look at making methods final specifically for optimization.  It
>     doesn't occur to me that the fact that it's overridable is a "leak"
>     in the API, it's at your own peril if you want to extend a class
>     that I didn't intend to be extendable.  Like changing/upgrading
>     engine parts in a car.
>
>
> Precisely, this highlights one of the key issues. Optimising has now
> become a dangerous breaking process.

Fifth.

[snip]

Allow me to summarize my understanding of the most valuable parts your 
argument.

* At the top level you believe ultimate efficiency should be default and 
OOP flexibility should be opt-in.

* Classes routinely should make most methods final because it's hard to 
imagine why one would override all but a few. Since those are a 
minority, it's so much the better to make final the default.

* Even the most performance-conscious people would not care to annotate 
classes and methods. It just doesn't happen. In contrast, people who 
want flexibility will annotate things for the simple reason they have 
to, otherwise overriding won't work.

* You don't consider it a problem that one must go back to base classes 
and changing methods from final to overridable, whenever such a need arises.

(It would be awesome if you had a similar list with the opposite arguments.)

If the above is an accurate summary, I'd say it's a matter in which 
reasonable people might disagree. I take issue with each of the points 
above (not flat out disagree with each, more like amend and qualify etc).

Unless fresh arguments, facts, or perspectives come about, I am 
personally not convinced, based on this thread so far, that we should 
operate a language change.


Andrei


More information about the Digitalmars-d mailing list