[wasm] reduce eval in production code

[pavelsavara]

Fixes #61287

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #61287

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	7.0.0

[pavelsavara]

cc @kg

[pavelsavara]

Sorry guys, I realized that there is still usage in the benchmark.
That also forced me to fix JSExport from nested class.

[lewing]

https://radekdoulik.github.io/WasmPerformanceMeasurements/?startDate=2022-07-11T19%3A31%3A11.000Z&endDate=2022-07-11T21%3A06%3A41.000Z&tasks=%2CAppStart&flavors=2

[kg]

https://radekdoulik.github.io/WasmPerformanceMeasurements/?startDate=2022-07-11T19%3A31%3A11.000Z&endDate=2022-07-11T21%3A06%3A41.000Z&tasks=%2CAppStart&flavors=2

The time increase in this doesn't make any sense given the change in question, seems like variance?

[lewing]

cae954a...4a2ebf2 is the only commit in the diff and it changes the test mechanism. it was known and mostly fixed with the lazy init I think

[pavelsavara]

Yes, I had to rewrite the benchmark to stop using eval code path and so I introduced dependency on JSExport into benchmark. The implementation at the time was triggering static constructors of the containing class during runtime init. That's now fixed in #77293

[radekdoulik]

https://radekdoulik.github.io/WasmPerformanceMeasurements/?startDate=2022-07-11T19%3A31%3A11.000Z&endDate=2022-07-11T21%3A06%3A41.000Z&tasks=%2CAppStart&flavors=2

yup, it is #75598 and Pavel fixed it in #77293. the static constructors were doing a lot of work, which was not needed during startup