X[]==Y[] is 7X slower than it should be -- why?

Sean Kelly sean at invisibleduck.org
Sun Jun 22 12:09:59 PDT 2008


== Quote from Tomas Lindquist Olsen (tomas at famolsen.dk)'s article
> Sean Kelly wrote:
> > == Quote from Sean Kelly (sean at invisibleduck.org)'s article
> >> == Quote from Tomas Lindquist Olsen (tomas at famolsen.dk)'s article
> >>> Sean Kelly wrote:
> >>>> == Quote from Jarrett Billingsley (kb3ctd2 at yahoo.com)'s article
> >>>>> "Sean Kelly" <sean at invisibleduck.org> wrote in message
> >>>>> news:g3gtvk$1tm7$1 at digitalmars.com...
> >>>>>> Done :p
> >>>>>>
> >>>>>> http://dsource.org/projects/tango/changeset/3651
> >>>>> In _adCmp,
> >>>>> if (a1.ptr == a2.ptr)
> >>>>>     return 0;
> >>>>> erm, that's not right at all.  Two slices with the same pointer and
> >>>>> different lengths.
> >>>> Darnit, you're right.  Good catch.
> >>>>
> >>>>
> >>>> Sean
> >>> After having a look at this I don't see how it could work.
> >>> The TypeInfo passed to _adEq/Cmp is the *element* typeinfo, not the *array*
> >> typeinfo.
> >>> With the current code, the way I read it, only arrays with elementsize==1 will
> >> work (and only
> >>> if the element is not a 1byte struct that overloads the comparison operators.
> >>> Am I missing something or should the compilers not be changed to pass the
> >> *array* typeinfo if
> >>> these optimizations are to make any sense ?
> >> I was wondering about that.  *sigh* I guess I'll have to change it back then.
 How
> >> terribly annoying.
> >
> > Hold on.  Why would that routine get the TypeInfo for the element and not the
> > array?  Similar typed arrays can only be compared anyway, and the differences
> > between static and sdynamic arrays are irrelevant for comparisons.  What am I
> > missing?  I'm inclined to just file a bug report asking that this be changed.
> >
> >
> > Sean
> Yeah, after writing my reply I wondered a bit about this and went on and changed
LLVMDC to pass
> the array's typeinfo :)
> There's really no reason no to make this change (besides forcing people to
recompile), the
> implementation becomes *both* cleaner and faster :)

Yup.  I made the change without really thinking about it because I assumed this is
how it was already implemented.  Oh well.  There are a bunch of weird little
quirks like this is the runtime.  If only I could fix the compiler when these
things come up as well :-p


Sean

P.S. http://d.puremagic.com/issues/show_bug.cgi?id=2161



More information about the Digitalmars-d mailing list