Function call performance improvements

[lahma]

I tried to return some of the performance that was lost with binding instantiation changes.

• use adapting map structures for DeclarativeEnvironmentRecord
• lazily materialize arguments when needed
• put test files to project ignore, just slows down the IDE
• add test case for running same code as arrow function, faster!

Jint.Benchmark.UncacheableExpressionsBenchmark

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.19041
Intel Core i7-6820HQ CPU 2.70GHz (Skylake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.101
  [Host]     : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
  DefaultJob : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Before

Method	N	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Benchmark	500	500.2 ms	2.39 ms	2.12 ms	150000.0000	28000.0000	-	598.52 MB

After

Method	N	Arrow	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Benchmark	500	False	246.2 ms	1.32 ms	1.17 ms	43000.0000	11000.0000	-	171.78 MB
Benchmark	500	True	197.6 ms	0.73 ms	0.65 ms	37333.3333	2000.0000	-	149.96 MB

[lahma]

Ready from my part, decided to use simpler HybridDictionary, about the same perf and more understandable than multi-level collection mutation that was there earlier.

[sebastienros]

So arrow functions are inherently faster because they don't expose the arguments object? Do you know if that's true also in v8?

[lahma]

Basically this https://www.ecma-international.org/ecma-262/10.0/index.html#sec-functiondeclarationinstantiation . We can skip object allocation and binding it to context. Especially for small arrows like array.filter this extra work adds runtime, also no need to worry about pooling etc. V8 probably has some black magic, might not show up there that much...