Small Buffer Optimization for string and friends

Manu turkeyman at gmail.com
Sun Apr 8 07:26:44 PDT 2012


On 8 April 2012 12:54, Manu <turkeyman at gmail.com> wrote:

> On 8 April 2012 12:46, Vladimir Panteleev <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?
>

The only way I can see this working is if the marker happens to be the top
bit of the size (limiting arrays to 2gb on 32bit systems, which is probably
fine), and if set, the next 7 bits are the size, leaving 7 bytes for a
string... 7 bytes is pushing it, 15 bytes is very useful, 7 is borderline...

That all said, I'll ultimately end out with my own string type anyway which
is multiples of, and aligned to 16 bytes, which will support SSE string
opcodes. I wonder if these considerations can be factored into the built-in
string?

Is it realistic that anyone can actually use raw d-string's in an app that
performs a lot of string manipulation? I bet most people end up with a
custom string class anyway...
Who's written a string-heavy app without their own string helper class? I
ended up with a string class within about half an hour of trying to work
with D strings (initially just to support stack strings, then it grew).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120408/c333d9e8/attachment.html>


More information about the Digitalmars-d mailing list