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