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