integrate (by hand) #18353 and #18359 from maint-5.8:
authorHugo van der Sanden <hv@crypt.org>
Tue, 21 Jan 2003 01:37:03 +0000 (01:37 +0000)
committerhv <hv@crypt.org>
Tue, 21 Jan 2003 01:37:03 +0000 (01:37 +0000)
commit7e8c5daceba7cb185532328a3b67d4ca7ba4811b
tree6fbcb357ec74beb075b5c99dbc3f3ac52e68114f
parent388cc4de5f48b02cc9fe9b962f02cf603af02178
integrate (by hand) #18353 and #18359 from maint-5.8:
Introduce a cache for UTF-8 data: length and byte<->char offset
mapping are stored in a new type of magic.  Speeds up length(),
substr(), index(), rindex(), pos(), and some parts of s///.

The speedup varies a lot (on the usual suspects: what is the
access pattern of the data, compiler, CPU), but should be at
least one order of magnitude, and getting to the same magnitude
as byte string speeds, and in some cases  (length on unchanged data)
even reaching the byte string speed.  On the other hand, in some
cases (index) the byte speed is still faster by a factor of five
or so, but the bottleneck there does not seem to be any more
the byte<->char offset mapping (instead, the fbm_instr() speed).

There is one cache slot for the length, and only two for the
byte<->char offset mapping (the first one for the start->offset,
and the second for the offset->offset+length, when talking
in substr() terms).

Code this hairy is bound to have hairy trolls hiding under it.
[...]
A small tweak on top of #18353: don't display mg_len bytes of
mg_ptr for PERL_MAGIC_utf8 because that's not what's there.

p4raw-id: //depot/perl@18530
dump.c
embed.fnc
embed.h
mg.c
perl.h
pod/perlapi.pod
proto.h
sv.c
util.c