[Issue 7515] The new std.string.translate is slow for ASCII text

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7515



--- Comment #7 from Jonathan M Davis <jmdavisProg at gmx.com> 2012-03-11 14:22:41 PDT ---
If you want a truly generic mapping function which operates on ubyte and
creates an array which holds all of the possible values of that type, then it
makes no sense to be putting it in std.string. It should be more generic and be
in std.array (though given that it wouldn't really make sense to do what
makeTrans and translate are doing with anything larger than a ubyte, I question
how good an idea that would lbe).

If what you care about is strings, then there is no point in having an array
greater than 128 elements long, because there aren't any ASCII characters
greater than that. Having 256 is pointless and wasteful, because there won't be
any characters that large. Not to mention, the _whole_ reason that you were
complaining about this in the first place was because the unicode-aware version
of translate was slower than using maketrans/trnslate when dealing with pure
ASCII, and using 128 elements is going to be faster.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------