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