Slow performance compared to C++, ideas?
Jonathan M Davis
jmdavisProg at gmx.com
Mon Jun 3 19:51:41 PDT 2013
On Monday, June 03, 2013 22:25:13 Andrei Alexandrescu wrote:
> It's useless to focus on the breakage override has caused. Yes it did
> cause breakage. There is no conclusion to draw from that without
> considering the considerably complex dynamics surrounding the whole
> matter (experience, benefits, number of users affected positively and
> negatively).
>
> To use that breakage as an argument linked to absorbing breakage caused
> by switching to final-by-default does not make sense. I'll try to
> abstain replying to this particular point in the future, it just
> instantly lowers the quality of the dialog.
The comparison is made because we're talking about a related change, and the
actual breakage caused by override was fairly recent, so while the decision to
cause that breakage was made quite some time ago, we were still willing to
cause that breakage fairly recently, so the implication then is that it would
be acceptable to do something related which causes less breakage.
Now, that being said, I do think that we need to look at this change in its
own right, and it needs to justify itself, but clearly folks like Manu think
that it does justify itself and feel that there's something off if we're
willing to make the change with override and not this one, when they're
related, and this one causes even less breakage.
I do think that virtual-by-default was a mistake and would like to see it
fixed, but I'm also not as passionate about it as Manu or Don. Manu in
particular seems to be sick of having to fix performance bugs at Remedy Games
caused by this issue and so would really like to see non-virtual be the
default. The folks using D in companies in real-world code seem to think that
the ROI on this change is well worth it.
And a technical issue which affects us all is how this interacts with
extern(C++). Daniel Murphy is having to improve extern(C++) in order to be
able to port the dmd frontend to D (so that it can properly interact with the
backends), and the fact that member functions are virtual by default definitely
causes problems there. He would know the details about that better than I
would, but IIRC, it had to do with the fact that we needed to be able to
interface with non-virtual member C++ functions. So, depending on the details
with that, that alone could make it worth switching to non-virtual by default,
particularly when the breakage is actually quite loud and easy to fix.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list