GoogleCodeExporter
commented
9 years ago Hi @lostfreeman,
Thanks for creating this issue. It is worth tracking, and I will keep it on my
radar, but I'm not sure switching to DLR instead of Reflection will actually
reap net benefits. I'm not 100% sure about the details of the DLR, but consider
the following.
The F# PowerPack quotation evaluator uses DLR Expression Trees to compile and
evaluate F# quotations. It was because of several bugs, missing features, and
performance issues that I abandoned it in favor of my own hand-rolled
reflection-based implementation.
The bugs and missing features are due to the impedance mismatch between
Expressions, which were designed with statement-based languages like C# and
VB.NET in mind, and F# Quotations. That is, converting Quotations into
Expressions requires twisting the latter in a way that they weren't designed
for. And certain expressions, like PropertySet, can't be supported at all.
True, Reflection.Emit could be used over Expressions, but that would be
near-prohibitive exercise (consider creating and applying functions, for
example). On-the-other-hand, evaluating Quotations using reflection is very
direct (robust with a mere 300 lines of code).
Regarding performance, I think reflection-based evaluation is actually superior
to what can be achieved with the DLR for Unquote's use-case. That is, the DLR
excels at optimizing repeated calls to dynamic code, but Unquote only executes
test methods once per test run. The overhead of converting Quotations into
Expressions and then compiling those expressions only to invoke them once is
quite large, and I've measured significant performance improvements from
Unquote's reflection-based evaluator over the F# PowerPack Expression-based
evaluator.Original comment by stephen....@gmail.com on 14 Oct 2012 at 3:25
Original issue reported on code.google.com by
lostfree...@gmail.comon 14 Oct 2012 at 4:29