On Sunday, February 03, 2013 02:27:16 Era Scarecrow wrote:
> On Saturday, 2 February 2013 at 15:47:37 UTC, FG wrote:
> > Yeah but let us move reallocation out of the equation. Reserving space limits the amount of RAM used and can avoid reallocations all together but in a little test it came out that still appender is 2.5-4 times faster than tab ~= str, where tab is char[] (same when it is ubyte[]). Why is that?
> 
>   Reserving doesn't mean it has to allocate any memory at all;
> That's up to the implementation of the runtime and OS, it may
> just say 'any allocations not related to this object start after
> address xxx', then as the reserved space needs more it requests
> the larger space from the OS. The limitations of how much you can
> use memory-wise doesn't change as that's determined by the
> infrastructure. (VM and harddrive space doesn't count).

reserve should guarantee that you have at least the requested amount of memory already allocated, or it's broken. Its whole purpose is to guarantee that capacity is at least as large as the amount being reserved so that you can do a single allocation up front rather than having to worry about reallocations occuring as you append.

- Jonathan M Davis

On Sunday, 3 February 2013 at 01:41:26 UTC, Jonathan M Davis wrote:
> reserve should guarantee that you have at least the requested amount of memory already allocated, or it's broken. Its whole purpose is to guarantee that capacity is at least as large as the amount being reserved so that you can do a single allocation up front rather than having to worry about reallocations occurring as you append.

 Allocated, set aside, uninterrupted continuous block, etc. As long as the space is actually available when it's needed it's implemented doesn't matter. In the end it's up to the OS.

 The OS could be using Virtual Memory space by compressing data, then decompressing when it's requested/needed; In that case the data pre-allocated is empty (zeroed) it can compress instantly to almost nothing (Compressed swapfile driver in Linux for example). The most important part is making sure nothing else can claim any memory in the reserved block.

On Saturday, 2 February 2013 at 15:39:00 UTC, Namespace wrote:
>> I've never come across Appenders before. Could you please explain them a little bit, and what each call in your modified code does?
>>
>> Thanks,
>>
>> Josh
>
> http://dlang.org/phobos/std_array.html#.Appender
> And read Era's post.

Why Appender has no ~ operator itself?

auto app = appender!string();
app.put("a");  // why not app ~= "a"?

Andrea Fontana:

> Why Appender has no ~ operator itself?
>
> auto app = appender!string();
> app.put("a");  // why not app ~= "a"?

Now it's in GIT head.

Bye,
bearophile

On Wed, 13 Feb 2013 17:00:39 +0100, bearophile wrote:
> Andrea Fontana:
>> Why Appender has no ~ operator itself?
>>
>> auto app = appender!string(); app.put("a");  // why not app ~= "a"?
> 
> Now it's in GIT head.

That's a nice touch.  Good idea, Andrea :)


-- 
Lee

On Wednesday, 13 February 2013 at 15:53:44 UTC, Andrea Fontana wrote:
> Why Appender has no ~ operator itself?
>
> auto app = appender!string();
> app.put("a");  // why not app ~= "a"?

Because Appender is an output range, using ~= will mean your code will not work with other output ranges.