<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I hope this comment was not in my doc?<br></div></blockquote><div><br></div>It's a parenthetical in the paragraph starting with "Finally, ultimately, the user is probably the most happy with an API that directly accepts the units in which they are already measuring their string"<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr">
      </div>
    </blockquote>
    <p>You mean the _byte size_ of the encoded string (rather than
      number of code units?)</p></div></blockquote><div>Yes, exactly.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>Something like this might be interesting. That said... if the
      charset matches, then creating the segment view, then obtaining
      its byte size is O(1) (e.g. no decoding). And if the charset
      doesn't match, you'll need to decode anyway -- at which point I'm
      not sure the array creation is really the bottleneck?</p></div></blockquote><div>Thanks, yes, MemorySegment.ofString seemingly solves the case where the charset matches, so it's more a question of whether there are performance gains to be had for the case where the charset doesn't match. The benchmarking I've seen suggests a carefully optimized loop over the string is outperforming getBytes(charset).length for that case. I can do some more analysis and report back.</div></div></div>
</div>