Small Buffer Optimization for string and friends

[Artur Skawina]

On 04/10/12 07:01, Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:jlut8k$j4o$1 at digitalmars.com...
>>
>> I agree. So we have the counterarguments:
>>
>> 1. Lowering would treat array primitives as sheer D code, subject to 
>> refusal of inlining. That means worse performance.
>>
> 
> So in other words, we need the @forceinline that some people have strongly 
> requested? Make it work even without -inline, and then add -noinline for any 
> rare cases where someone might need to forcefully disable @forceinline. 
> Shouldn't that take care of it?

Obviously, yes, but should wait until enough attribute support is in place and
not be just a @inline hack (no point in naming it forceinline - there's no
other kind of inline).

>> 2. Unless the compiler takes special measures, source-level debuggers will 
>> trace through core, uninteresting code for array operations.
>>
> 
> Would @forceinline fix this?

No, but the compiler could just omit the debuginfo for the lowerings, unless
requested with a flag.

>> 3. There are patterns that attempt to optimize by e.g. using .ptr, but end 
>> up pessimizing code because they trigger multiple memory allocations.
> 
> Someone's suggestion of just making .ptr null instead of doing implicit 
> allocations was an interesting idea.

I hope that wasn't a serious suggestion. What might be possible is passing
strings by reference and atomically changing the representation when (if) a
pointer is needed. That would have problems too (ABI change, can't have RO
strings, can't keep the small strings in registers etc).
Doing the small buffer optimization for a new type may be possible, but trying
to add it to the current char[] arrays is probably not a good idea.

artur