Small Buffer Optimization for string and friends

Manu turkeyman at gmail.com
Sun Apr 8 08:03:00 PDT 2012


On 8 April 2012 17:52, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>wrote:

> On 4/8/12 4:54 AM, Manu wrote:
>
>> On 8 April 2012 12:46, Vladimir Panteleev <vladimir at thecybershadow.net
>> <mailto:vladimir@**thecybershadow.net <vladimir at thecybershadow.net>>>
>> wrote:
>>
>>    On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote:
>>
>>        Walter and I discussed today about using the small string
>>        optimization in string and other arrays of immutable small objects.
>>
>>        On 64 bit machines, string occupies 16 bytes. We could use the
>>        first byte as discriminator, which means that all strings under
>>        16 chars need no memory allocation at all.
>>
>>
>>    Don't use the first byte. Use the last byte.
>>
>>    The last byte is the highest-order byte of the length. Limiting
>>    arrays to 18.37 exabytes, as opposed to 18.45 exabytes, is a much
>>    nicer limitation than making assumptions about the memory layout.
>>
>>
>> What is the plan for 32bit?
>>
>
> We can experiment with making strings shorter than 8 chars in-situ. The
> drawback will be that length will be limited to 29 bits, i.e. 512MB.


29 bits? ...not 31?
How does this implementation actually work? On 32/64 bits, and little/big
endian?
I can only imagine it working with a carefully placed 1 bit. bit-0 of the
size on little endian, and bit-31 of the size on big endian. That should
only halve the address range (leaving 31 bits)... where did the other 2
bits go?

I also hope this only affects slices of chars? It will ignore this
behaviour for anything other than char arrays right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120408/4234ac80/attachment.html>


More information about the Digitalmars-d mailing list