Support compilation without closure collection phase for expression with nested lambdas

[dadhi]

Related to

• https://github.com/dadhi/DryIoc/issues/211
• https://github.com/dadhi/DryIoc/pull/268

Currently, FEC has a TryCompileWithPreCreatedClosure method with limited functionality without nested lambdas support.

We may enable it so that big and deep expressions may skip the closure collection phase improving the performance and saving the memory.

Todo:

• Split constants and nested lambdas into the different arrays in ArrayClosure so they could be set independently. It should not affect the memory much because it is just plus one pointer.
• Allow to use and share a single closure between the top and nested lambdas. At least for the case without top non-passed parameters used in the nested lambda - which is the majority of cases.
• Decide on how to provide the constant usage to the method OR simplify it away by always storing and loading the closure constants in local variables - considering the multiple usages of one constant to be the most often use-case.
• Keep the same "the same nested lambda compiled once" mechanism via sharing the expression and compiled lambda in NestedLambdaInfo.

[dadhi]

Couple of questions to answer:

• Why do we collecting constants multiple times for the same sub-expression? Can we do better, at least for New or Call expressions. We need to test this.

  • Today we are not collecting constants twice for the nested lambdas or do we?
  • We may keep two separate lists for already traversed constructors and methods. This will speed up the check for traversed expressions while collected without the cost of using the dictionary.

• Does it better to use a single closure constants array for all root and nested lambdas, it should take less memory but may be harder to collect because the array is larger, or the first point will help?

  • Yes, it may be safe because the constants (and compiled nested lambdas) are immutable. So it does not matter where to hold them - in a split or a single list.
  • It may help to get rid of an object holding both compiled open-delegate nested lambda + its closure constant array (the array then is used together with non-passed params or variables to construct the final closure). The constants array would be available from the parent lambda closure, so final nested closure will look like new ArrayClosure(sharedConstAndNestedLambdas, new object[...nonPassedParams])
  • In order to peek the constants from the shared list, we still need to keep constant usage indexes array in ClosureInfo
  • We may decide on a simpler constant loading into variables approach - if usage is not empty then we will always load every constant into its own variable. A small optimization would be to not load constants array field and access it directly if the usages count is less than 3.