[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 #8 from bearophile_hugs at eml.cc 2012-03-11 14:40:45 PDT ---
(In reply to comment #7)

Thank you for your answers.

> 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).

I have not asked for a truly generic function for std.array. So this problem
doesn't happen.


> 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.

Now I have had to use translate() for a different job: I have a good amount of
8-bit ASCII text in my language to process
(http://en.wikipedia.org/wiki/Extended_ASCII ). It's not Unicode, and I don't
think I can convert it to Unicode. I have to use translate() on this text. A
128-elements translate() isn't enough.

The "waste" caused by using a 256 items array instead of a 128 items array is
probably not significant.

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