IMHO (I'm 99.999% sure Andrei will disagree with me) if you really want to exploit every possible micro-optimization you shouldn't be using generic code in the first place. The ability to write generic code that's as efficient as the equivalent hand-written code is a major achievement of templates. However, if you know your data and use cases inside out and care about getting every last bit of performance, you won't write equivalent hand-written code, you'll write super micro-optimized hand-written code tailored to the data and use case. There are almost always opportunities for ad-hoc micro-optimization, though whether they are worth implementing in any given case is a different question.
On Fri, Aug 13, 2010 at 2:00 PM, Jonathan M Davis <[email protected]>wrote: > On Friday, August 13, 2010 10:32:11 David Simcha wrote: > > I would agree if we were talking about big-O efficiency, or even a large > > constant overhead, but IMHO avoiding Slicer is a micro-optimization, not > a > > macro-optimization. Therefore, by default it should "just work" even if > > it's slightly inefficient and intervention should be required only if the > > programmer decides it needs to be optimized. > > Well, if it's deemed that it's not a big difference, then I don't think > that I > really have a problem with it. It bugs me a bit still, but that doesn't > mean > that it's a bad idea. We definitely need std.algorithm to generally be > efficient, > but we also need it to be useable. So, if the cost in efficiency is small > enough, > and there really are a lot of ranges that have this problem, then Slicer > probably should be used. > > - Jonathan M Davis > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
