Small Buffer Optimization for string and friends

Michel Fortin michel.fortin at michelf.com
Sun Apr 8 12:56:10 PDT 2012


On 2012-04-08 18:30:49 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 4/8/12 1:26 PM, Andrei Alexandrescu wrote:
>> On 4/8/12 1:16 PM, Michel Fortin wrote:
>>> Also, if the variable is a temporary copy such as a by-value function
>>> parameter, only the representation of that temporary copy will be
>>> affected. Every time you call a function which calls .ptr a new copy
>>> will be allocated on the heap. If such a function call is part of a
>>> loop, it'll degrade performance noticeably.
>> 
>> I think there's a bit of a confusion. Could you please clarify with an
>> example?
> 
> I think I understand:
> 
> string s;
> foreach (lots)
>    fun(s);
> 
> void fun(string s)
> {
>      ... s.ptr ...
> }

Exactly.

> I agree in this case there would be one allocation per call.

Basically, it's the same problem as receiving a const(char)[] as a 
function parameter and .idup-ing it in the function. The recommendation 
is for such functions to accept only immutable(char)[] and let the 
caller find a way to send an immutable string. That way, if the caller 
is repeatedly using the same string, it can reuse the efficient 
representation.

The same principles apply here: if your function needs to use .ptr, it 
should request a type on which you can call .ptr efficiently and let 
the caller find a way to pass think kind of string. To me, your small 
buffer optimization proposal looks like an argument in favor of 
creating a separate string type free from the constrains of offering at 
all time bare access to the bytes. If only that type could be the 
default...


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list