fixes #615 improve engine creation performance

[lahma]

• we already have lazy initialization support for arguments instance, so I derived a solution where objects are initialized lazily
• first access to features initializes objects, so if you don't use Map, it won't allocate or initialize
• no performance impact on earlier benchmarks

Before

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
EngineBenchmark	56.49 us	0.0473 us	0.0442 us	26.9775	0.1221	-	110.51 KB
EvaluationBenchmark	791.4 us	0.7033 us	0.6578 us	138.6719	-	-	570.16 KB
UncacheableExpressionsBenchmark	225.8 ms	0.1986 ms	0.1858 ms	30333.3333	333.3333	-	122.57 MB

After

• memory allocations reduced 92%
• minimal initialization and simple script run reduced 95%

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
EngineBenchmark	2.745 us	0.0093 us	0.0078 us	2.1248	-	-	8.72 KB
EvaluationBenchmark	796.4 us	1.711 us	1.601 us	138.6719	-	-	570.16 KB
UncacheableExpressionsBenchmark	223.4 ms	0.1680 ms	0.1571 ms	30333.3333	333.3333	-	122.57 MB

[sebastienros]

I think it should be a huge gain for ravendb also. Will benchmark it on Orchard tomorrow, because we don't even use all these objects.

[lahma]

@sebastienros did you ever find the time to compare performance in Orchard?

[sebastienros]

I remember I checked and it was faster but don't recall the numbers.

[lahma]

Great, thanks for the update 🙂

[sebastienros]

if you like perf, there is so much to do in Orchard. It's allocating like crazy, which is not surprising because it does stuff ;) but which also means there are many ways to improve it.

[lahma]

Maybe at some point, probably requires quite a lot studying to understand hot paths and important scenarios...

[viceice]

Why was this done? It is now no longer possible to override with a custom ITypeConverter

[lahma]

Just an oversight. Maybe submit a PR with a test case that protects from happening again?

[viceice]

See #654 for pr