new std.variant (was Re: The Right Approach to Exceptions)
sandford at jhu.edu
Wed Feb 22 15:03:48 PST 2012
On Wed, 22 Feb 2012 14:17:09 -0600, Jonathan M Davis <jmdavisProg at gmx.com>
> On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote:
>> On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
>> > There's a big difference between sealed and not accessible. .data's
>> > requires exposing an array, and there's no way to do this without
>> > memory like a sieve in one way or another. However, if all you need
>> is to
>> > iterate the contents, that's easy to do. I'm currently adding
>> > iteration. Even indexing is fairly efficient (not yet implemented),
>> > particularly relative indexing (i.e. n from back or front).
>> > I haven't seen too many use cases yet where accessing the underlying
>> > is important, nor has it come up on bugzilla. I've found one case in
>> > Phobos where appender was used as a stack. What's your example? What
>> > features does it have to support and how efficient does it have to be?
>> It's can be useful to just get at the underlying array and pass it to
>> functions which are going to use it but not alter it (or at least not
>> to it). Iterating over it doesn't give you an array. And since
>> entire purpose is simply to make appending to an array more efficient,
>> making it impossible to treat it as one until you're done appending is
>> overly restrictive IMHO. Yes, if you leak references to the underlying
>> data, you're asking for trouble, but that doesn't mean that it can't be
>> used without leaking memory.
>> Unfortunately, I don't have any code snippets with me at the moment, so
>> can't give any concrete examples of usage, but any situation where you
>> to be able to operate on the array while building it needs the ability
>> get at the underlying array. Yes, in most cases, you're probably simply
>> appending to the array, but at least once in a while, you need to
>> on an array while building it.
> Also, wouldn't it be less efficient if you _had_ to copy the array once
> you were
> done with the appender? That would seem to go against what appender is
> to do.
> - Jonathan M Davis
No, because the array doesn't actually exist until appender makes copy.
Internally, appender is using a list of arrays to store the data (similar
to a VList and string builders from other languages). So it's little o(2N)
for both memory and speed; the current appender is much worse than that.
In terms of actual performance, on a clean machine I'm substantially
faster for N < 4k (thanks to a free list), about the same for things of a
few k in size, and then as things get bigger the current appender tanks.
More information about the Digitalmars-d