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