Use case: eliminate hidden allocations in buildPath
Michel Fortin
michel.fortin at michelf.ca
Sat Dec 7 10:27:07 PST 2013
On 2013-12-07 16:08:18 +0000, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> said:
> On 12/7/13 5:13 AM, Michel Fortin wrote:
>> You have to admit that a "bump the pointer" allocator is pretty much the
>> same thing as an output range that fills a preexisting array.
>
> Only of the output range is untyped. An allocator traffics in untyped
> chunks; an output range usually has an element type.
If I remember well, you said before that you may also design "typed
allocators" that'd work at a layer above untyped allocators. That's
what I was referring to, although I wasn't very clear (the words "typed
allocator" only appeared after the paragraph quoted above).
Anyway, here's another thing to consider in the Output Range vs.
Allocator debate: allocators can be faster than output ranges because
you can tell the allocator in advance how much data you need.
For instance, if you're joining multiple strings together you can
quickly calculate the final length, allocate that, write to allocated
memory and return the result. In fact, that's exactly what buildPath
currently does when allocating from the GC.
With an output range that appends to a string the string needs to
constantly grow to accommodate new content, with no insight as to the
final length. The way to fix that with an output range would be to have
have a "reserve" function telling the range "prepare yourself to
receive that much data", which may or may not do something depending on
the kind of output range it is. There's no such function in the
definition of an output range right now.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca
More information about the Digitalmars-d
mailing list