As Thanksgiving is over, and as work towards 24-RDP1 should mostly be
done, I think it is a good time to resume our now.
To kick-off, below I am repeating my last response to Chen. Kindly
asking everybody to chime in, so we can find a feasible and
beneficial conclusion in this area.
-Markus
*Von:*Markus Karg [mailto:mar...@headcrashing.eu]
*Gesendet:* Sonntag, 27. Oktober 2024 09:44
*An:* 'core-libs-dev'
*Betreff:* Request for Comments: Adding bulk-read method
"CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int
dstBegin)"
>Hi Markus,
>Should we drop the srcBigin/srcEnd parameters, as they can be replaced by a
subSequence(srcBegin, srcEnd) call?
Chen, I do understand your idea and while originally I had the same
in mind (it really /is/ appealing!), I came up with a draft using the
*original* String.getChars()signature instead, due to the following
drawbacks:
* There might exist (possibly lotsof) CharSequence.getChars(int,
int, char[], int)implementations already, as this problem (and
the idea how to solve it) is anything but new. At least such
implementations are String, StringBuilderand StringBuffer. If we
come up with a different signature, then *none* of these already
existing performance boosters will get used by
Reader.of(CharSequence)automatically - at least until they come
up with alias methods. Effectively this leads to (possibly lots)
of alias methods. At least it leads to alias methods in String,
StringBuilder, StringBufferand CharBuffer. In contrast, when
keeping the signature copied from String.getChars, chances are
good that (possibly lots of) implementations will /instantly/ be
supported by Reader.of(CharSequence)without alias methods. At
least, String, StringBuilderand StringBufferwill be.
* Since decades people are now very used to
StringBuilder.getChars(int, int, char[], int), so (possibly a lot
of) people might simply /expect/ us to come up with that lengthy
signature. These people might be rather confused (if not to say
frustrated) when we now force them to write an intermediate
subSequence(int, int)for something that was "such simple" before.
* Custom implementations of CharSequence.subSequencecould come up
with the (performance-wise "bad") idea of creating *copies*
instead of views. At least it seems like AbstractStringBuilderis
doing that, so chances are "good" that custom libs will do that,
too. For example, because they need it for safety. Or possibly,
because they have a technical reason that /enforces/ a copy. That
would (possibly massively, depending on the actual class) spoil
the idea of performance-boosting this RFC is all about.
-Markus
