On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts <bra...@puremagic.com>
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From
reading some
disassemblies, the reason seems to be because of all the ASM code that's
required for lazy parameters. I wonder if either of the following is
feasible:
1. When a function takes a lazy parameter, the compiler automatically
generates two versions under the hood: One that actually takes a
non-lazy
parameter and is used when the value is known at compile time and
another that
works like current lazy functions. The only problem here is that this
might
create issues when using function pointers/delegates.
2. Allow overloading of lazy and non-lazy functions, with the rule
that the
lazy version gets called whenever the value must be computed at runtime
and
the non-lazy version gets called if the value is statically known and
thus
there's no evaluation to speak of.
It's the throw that blocks inlining right now. Lazy might also disable
inlining
too, I haven't looked for that case. Either way, that's purely a
quality of
implementation issue. I don't think it'd be a good idea to bend the
library all
that much to work around that kind of limitation. It's something that
will get
better as time permits.
Well, there's something to be said about preventing the bloated generation
of code that accompanies lazy.
But throwing preventing inlining is a bad one, that should be fixed.
-Steve
