Algorithms & opApply

[dsimcha]

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
> http://d.puremagic.com/issues/show_bug.cgi?id=4264
> Currently (SVN) only array() is able to digest iterables that define opApply
only, but I think a few more spread support will be very good.
> In the thread of that 4264 there are plenty of comments and views of the
situation. Opinions welcome, both here and there.
> Bye,
> bearophile

I've started looking into the performance aspects of supporting opApply in
std.algorithm and std.range where possible.  I created quick and dirty Map, Filter
and Until opApply-based iterables for D1.  I then instantiated them with int[]
arrays and some trivial (as in, compile to a single instruction) predicates,
compiled them on LDC with full optimizations and started reading some
disassemblies.  It seems even LDC is too stupid to fully inline cases where Map is
stacked with Filter.  Things seem to get partially inlined in the most arbitrary
ways, even though Map gets fully inlined when used alone.  Even stranger, the
delegate calls get converted to direct function calls, even though they don't get
inlined.

I wonder if this is a weakness of compiler inlining heuristics in general, though.
 When you stack a whole bunch of trivial function calls together, such these
function calls would compile down to a handful of instructions if every single one
of them was inlined, is this just an ugly corner case in the imperfect heuristics
compilers use to inline functions?  If so, now I understand why old-school
programmers don't trust compilers.