String compare performance

[spir]

On Sun, 28 Nov 2010 10:48:46 -0500
bearophile <bearophileHUGS at lycos.com> wrote:

> generally I don't like to use find, empty and popFront to solve this problem, it's quite unnatural. Here I have explained what I think is a good enough solution to this performance problem:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123044

What I would like is a just decent routine for comparing arrays of elements which _conceptually_ are values, whatever their complexity (meaning, possibly structs or nested arrays). This should always (*) use a default '==' comparison, which in turn may perform a kind of memcomp.
I have no idea how to avoid bad perf such as shown by your tests, but this is really necessary. Tons of routines and algorithms use '==', and among the most used; str.find will perform an arbitrary number of '==' checks; and I don't even want to think at pattern matching ;-)

Denis

(*) I think that:
* If an element type is a value type, it should not overide opEquals. '==' should translate to equality of every sub-element. Else, there is something wrong in the design. But there may be use cases I overlook. (Eg metadata stored on the element itself?)
* A plain value may well refer to a "thing"/object, eg a wiget's outlook pointing to a color palette, in which case reference comparison is the right choice -- so, no complication.
* Real things (referenced objects, entities with self/id) should not have opEquals at all. They should be compare only by id, meaning using 'is'. This shows again the ambivalence of dyn arrays...
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com