Slow performance compared to C++, ideas?

[Timon Gehr]

On 06/02/2013 10:44 PM, Jonathan M Davis wrote:
> On Sunday, June 02, 2013 12:37:38 Andrei Alexandrescu wrote:
>> On 6/2/13 9:59 AM, Manu wrote:
>>> I've never said that virtuals are bad. The key function of a class is
>>> polymorphism.
>>> But the reality is that in non-tool or container/foundational classes
>>> (which are typically write-once, use-lots; you don't tend to write these
>>> daily), a typical class will have a couple of virtuals, and a whole
>>> bunch of properties.
>>
>> I've argued if no dispatch is needed just make those free functions.
>> _Everything_ in a class is supposed to be overridable, unless inherited
>> and explicitly "final"ized. It's sort of a historical accident that
>> things got the way they are. But in D we know better because we have the
>> module-level privacy model and UFCS. So we should break clean from history.
>
> There are four problems with that:
>
> 1. Very few programmers think that way. The normal thing in most every OO
> language is to put all of the functions on the class, so pretty much no one is
> going to make them free functions. Do you really expect people to put
> properties (what would have been getters and setters in other languages)
> outside the class? It's not going to happen. And by default, everyone takes a
> performance hit as a result (folks like Manu and Don wcare about that
> performance hit more than many of us, but it's still there).
> ...

Yup.

> 2. The class' functions are no longer encapsulated inside the class. For some
> programmers, this is a big deal. They want all of the class' functionality on
> the class where it's easy to find. Having UFCS makes using free functions less
> of a problem, but many programmers will absolutely hate the idea of putting
> their non-virtual functions outside of the class, so they won't do it, and
> they (and everyone using their code) will end up with virtual functions when
> the functions shouldn't be virtual.
>

This is 1. again. (The unit of encapsulation in D is a module.)

> 3. In many cases, putting a function outside of the class is a royal pain.
> This is particularly true with templated classes. If you have
>
> class C(T)
> {
>     private T _var;
> }
>
> and you want a property to give you var, you end up with something ugly like
>
> @property auto var(U)(U this_)
>      if(is(U V == C!W, W))
> {
>      return this_._var;
> }
>
> Do you really expect many programmers to be able to pull off complicated is
> expressions like that? _I_ have to look it up every time I use it. Sure, using
> free functions might work in simple cases, but it starts falling apart when
> you have to deal with stuff like templated types.
>

1. Just do

@property auto var(T)(C!T this_){ return this_._var; }

2. The is-expression is not that complicated. The latest release finally 
fixes the issue that you needed to specify a redundant identifier to 
make it work:

@property auto var(U)(U this_)if(is(U==C!T,T)){ return this_._var; }


> 4. It causes more ambiguities and compilation errors. If a function is on the
> class, it always wins. If it's a free function, then you potentially have
> ambiguities due to overload sets. Making sure that the function takes the
> exact type significantly reduces the problem, but someone else could easily
> create a function with the same signature which now conflicts with the one
> which is effectively supposed to be a member function.
> ...

Well, yes, but I think this will not be a huge problem in practise.
(The private symbol clash stupidity may exacerbate the problem when it 
occurs though.)

I wouldn't mind if the default changed. (But I currently cannot update 
my compiler anyway, because of hard-to-reduce forward reference bugs.)