String compare performance

[Iain Buclaw]

== Quote from Jonathan M Davis (jmdavisProg at gmx.com)'s article
> On Saturday 27 November 2010 22:13:39 Austin Hastings wrote:
> > On 11/27/2010 11:53 AM, bearophile wrote:
> > > While translating a common Python script to D, I have found something
> > > interesting, so I have reduced it to a little benchmark.
> > >
> > > Below there is the reduced Python2 code (it uses Psyco), and a little
> > > program to generate some test data. The timing of the first D2 version
> > > is not good compared to the Python-Psyco program (the generation of the
> > > *300 array is a quick thing), so I have created two more D2 versions to
> > > show myself that D2 wasn't broken :-)
> > >
> > > The reduced code looks like a syntetic benchmark, but it has about the
> > > same performance profile of a 60 lines long Python script (the original
> > > code was using xrange(0,len(...)-3,3)  instead of xrange(len(...)-3),
> > > but the situation doesn't change much).
> >
> > It's not clear to me if the point of your post is "how do I make this go
> > faster?" or "Waa! D underperforms Python by default".
> What I think is pretty clear from this is that at some point, some work needs to
> be done to optimize array comparisons when memcmp can be used instead of having
> to call the individual opEquals() of each element. It's not the sort of thing
> that's likely to be a priority, but it really should be done at some point.
> - Jonathan M Davis

Just food for thought. GDC uses memcmp when using string comparisons in the first
implementation.

if (codon == "TAG" || codon == "TGA" || codon == "TAA")

And it is still the slowest case of the lot.

Regards