On 04/10/12 07:01, Nick Sabalausky wrote: > "Andrei Alexandrescu" <[email protected]> wrote in message > news:[email protected]... >> >> 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
