Overhauling the notion of output range
dsimcha
dsimcha at yahoo.com
Mon Jul 12 11:31:04 PDT 2010
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> On 07/12/2010 12:55 PM, Steven Schveighoffer wrote:
> > On Mon, 12 Jul 2010 13:43:18 -0400, torhu <no at spam.invalid> wrote:
> >
> >> On 12.07.2010 18:48, Steven Schveighoffer wrote:
> >> [...]
> >>> So what happens when you call put(r, e) for one of these output
> >>> classes? Instead of just calling add(e), it calls (add((&e)[0..1]))
> >>> which in turn goes through some needless loop, which then ends up
> >>> calling add(e). I don't see why this is preferable.
> >>
> >> put(r, e) prefers to call r.put(e) for single element adds. Doesn't
> >> that take care of it?
> >
> > No, dcollections doesn't define put. But you could take a delegate to
> > add. The question is, why the prejudice against the single element
> > version when using a delegate as an output range?
> >
> > The fact that an output range can define a put function that takes a
> > single element, but you can't use a delegate just makes no sense to me.
> >
> > -Steve
> Efficiency?
> Andrei
But efficiency only matters some of the time, assuming the kind of inefficiency in
question is small constant term inefficiency (as is the case here) and not O(N!)
inefficiency or 1000-fold constant term inefficiency.
Calling a delegate once per element is inefficient, but not **that** inefficient,
and it's convenient at times, such as when the delegate will be used in contexts
other than as an output range. I think inefficiency is a poor excuse for not
supporting this, and the users of Phobos should decide on a case-by-case basis
whether calling a delegate for every element is efficient enough.
The following benchmark takes a whopping 830 milliseconds on my computer, for a
**hundred million** iterations:
import std.stdio, std.perf;
void main() {
void foo() {}
auto pc = new PerformanceCounter;
pc.start;
auto del = &foo;
foreach(i; 0..100_000_000) {
del();
}
pc.stop;
writeln(pc.milliseconds);
}
More information about the Digitalmars-d
mailing list