On Sunday, 4 January 2015 at 03:37:05 UTC, Andrei Alexandrescu wrote:
>> By the way, I think `typeid(a) == typeid(b)` is silly. It calls
>> object.opEquals on the `typeid`s. And if they're not identical, that in
>> turn calls object.opEquals on the `typeid`s of the `typeid`s. That
>> fortunately hits the `is` case, or we'd go on forever. All that only to
>> realize that `typeid(a).opEquals(typeid(b))` suffices.
>>
>> [1] http://dlang.org/operatoroverloading.html
>
> Interesting. Is a pull request in your future? :o) -- Andrei

No need. The actual code has it right: https://github.com/D-Programming-Language/druntime/blob/b3a8032e3960480a1588b3d1a4491808b4502d67/src/object_.d#L171

On Sunday, 4 January 2015 at 05:17:10 UTC, Martin Nowak wrote:
> +1 definitely makes sense, can you file an enhancement request
>
> https://issues.dlang.org

https://issues.dlang.org/show_bug.cgi?id=13933

On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
> It requires a `final bool opEquals(SameClass other)` method to avoid the virtual call.

`final bool opEquals(Object)` is enough, no?

On Sunday, 4 January 2015 at 15:02:39 UTC, anonymous wrote:
> On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
>> It requires a `final bool opEquals(SameClass other)` method to avoid the virtual call.
>
> `final bool opEquals(Object)` is enough, no?

No, then you'd still need a dynamic cast for the argument.

On Sunday, 4 January 2015 at 15:15:09 UTC, Martin Nowak wrote:
> On Sunday, 4 January 2015 at 15:02:39 UTC, anonymous wrote:
>> On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
>>> It requires a `final bool opEquals(SameClass other)` method to avoid the virtual call.
>>
>> `final bool opEquals(Object)` is enough, no?
>
> No, then you'd still need a dynamic cast for the argument.

Sure, but the method call doesn't need to be virtual. As far as I understand, they're independent issues.

bool opEquals(Object)           virtual call, dynamic cast
final bool opEquals(Object)     possibly non-virtual call, dynamic cast
bool opEquals(SameClass)        virtual call, no cast
final bool opEquals(SameClass)  possibly non-virtual call, no cast

On Saturday, January 03, 2015 19:37:16 Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/3/15 7:23 PM, anonymous wrote:
> > For reference, here is .object.opEquals (according to documentation[1]):
> >
> > bool opEquals(Object a, Object b)
> > {
> >      if (a is b) return true;
> >      if (a is null || b is null) return false;
> >      if (typeid(a) == typeid(b)) return a.opEquals(b);
> >      return a.opEquals(b) && b.opEquals(a);
> > }
> >
> > I see one fundamental source of overhead: The types degenerate to
> > Object, resulting in virtual calls that could be avoided. Maybe it'd be
> > worthwhile to templatize object.opEquals: `bool opEquals(A, B)(A a, B b)`.
>
> Good point. It's been discussed but rejected because druntime generally shuns templates. I think that resistance is mostly vestigial by now.

It needs to happen as part of getting opEquals and friends off of Object, but a Win32 compiler bug is currently preventing it from happening:

https://github.com/D-Programming-Language/druntime/pull/459 https://issues.dlang.org/show_bug.cgi?id=12537

Unfortunately, none of the compiler devs seem to have taken any notice of it, and I haven't had the time or expertise to figure it out myself. Otherwise, it probably would have been templatize before the last dconf.

- Jonathan M Davis

I've create a PR for a templated opEquals here (https://github.com/D-Programming-Language/druntime/pull/1087).  Currently it will not build without some changes in phobos, PR here (https://github.com/D-Programming-Language/phobos/pull/2848).  Using the new templated opEquals it fixed the overhead/performance issues as seen here:

compiled on windows(x64): dmd opEqualsTest.d -inline -O -release

run 1 (loopcount 10000000)
  x.x == y.x               : 11609 microseconds
  x.opEquals(y)            : 22303 microseconds
  x.opEquals(cast(Object)y): 146859 microseconds
  x == y                   : 37685 microseconds
run 2 (loopcount 10000000)
  x.x == y.x               : 7525 microseconds
  x.opEquals(y)            : 7528 microseconds
  x.opEquals(cast(Object)y): 106771 microseconds
  x == y                   : 37251 microseconds

As you can see the '==' operator is now much close to the direct call to opEquals.  There is still some minimal overhead (I think caused by an extra function call and some null checks) but it is much closer.  I'm still working on the PRs but this may be a good solution.