Compact Strings and APIs for fast decoding of string data

[Chris Vest]

The OneShortStringBuilder looks nice. I would have to specify the Charset in its constructor, or somehow specify the capacity in bytes rather than characters, for it to optimally allocate the underlying byte array. It’s otherwise very similar, though probably more generally useful, to the builder I suggested in the beginning.

Cheers,
Chris

> On 10 Feb 2016, at 17:01, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> On 02/10/2016 02:16 PM, Chris Vest wrote:
>> I’m slightly more worried about their array and what it implies, though. This API requires of me that I’m able to present all of the relevant buffers up front. In my case, these buffers are shared between multiple threads, so they are guarded by locks. I must take all the locks for all the buffers and hold them for the duration of the copy._Maybe_  I have to do that anyway, but if there’s a way for me to only lock one buffer at a time, I’d like to be able to exploit this. The builder approach holds this door open for me.
> 
> In that case, you can't estimate the String array length upfront and you are forced to do copying afterwards. So you have to choose what is more important for you. Or do you have a case where the lengths of buffer sub-ranges are known in advance and you only want to gather their content one-by-one?

I’m not entirely sure what you are telling me. I know from the start what length of String I want in the end, but I’d prefer to feed it buffers one-by-one. The slice I need out of each buffer will definitely differ from buffer to buffer, and I probably can’t tell up-front how many buffers I’ll use without also taking all their locks up-front - this I’d like to avoid, and instead only take my locks as I need them, and hold them for as short a duration as possible.

> 
> Regards, Peter
> 
>> 
>> Cheers,
>> Chris
>