Hi,
Doing a simple stress test to see if the ScriptLibrary release scripts suffer leakage due to repetitive compilation. Doing the test freezes up VS 2013 to the point where you have to kill it using Task Manager. Nothing in the IDE responds to anything after trying to set a breakpoint while the test is running for a while. It seems to get incrementally slower also as the loop runs longer.
```
[TestMethod]
public void TestMethod1()
{
var b = new StringBuilder();
b.AppendLine("using System;");
b.AppendLine("public class Script {");
b.AppendLine(" public int Sum(int a, int b) {");
b.AppendLine(" return a+b;");
b.AppendLine(" }");
b.AppendLine("}");
for (int n = 0; n < 1000000000; n++)
{
dynamic script = CSScript.Evaluator.LoadCode(b.ToString());
int result = script.Sum(10, 20);
}
GC.Collect();
GC.WaitForFullGCComplete(10000);
Console.WriteLine("Done");
}
```
Comments: Indeed dynamic code execution can lead to the memory leaks. Though these leaks are not typical unfreed references (e.g. event handlers) but the assemblies that cannot be unloaded from the AppDomain. This is the fundamental CLR design limitation that was there from the start of .NET. CS-Script doesn't implement its own Evaluator and instead its hosts Mono.CSharp.Evaluator. Your call LoadCode gets redirected immediately to the Mono.CSharp.Evaluator.Compile(). And the memory management is also controlled by Mono. Thus I cannot really give you any solution for the problem as Mono is suffering from the "assembly leaks" the same way as any other framework. Saying that I found that some hosting scenarios engage some sort of caching in Mono runtime and that in turn creates some "leak free" opportunities. However the users reported that these scenarios are not deterministic nor reliable. All this discussed in details here: [http://www.csscript.net/help/evaluator.html](http://www.csscript.net/help/evaluator.html). There is a dedicated section "Limitations". CS-Script downloadables also contain an intesive memory stressing sample _MemoryManagement.cs_ that tests not only yours but other hosting scenarios as well. While "assembly leaking" is a curse that MS already officially refused to fix there is a work around. CS-Script (as opposite to Mono and Roslyn) recognized the problem and provided a built in mechanism for (not assembly) but AppDomain loading/unloading. Though the solution is only possible for the CodeDom hosting model (samples are provided). This is how a typical hosting code looks like: ```C# string asmFile = CSScript.CompileCode("<code>"); using (var helper = new AsmHelper(asmFile, null, true)) { IScript script = helper.CreateAndAlignToInterface<IScript>("*"); script.Hello("Hi there..."); } ``` Note: CodeDom also allows script debugging (Mono doesn't). You will find more details here: [http://www.csscript.net/help/Script_hosting_guideline_.html](http://www.csscript.net/help/Script_hosting_guideline_.html)
Doing a simple stress test to see if the ScriptLibrary release scripts suffer leakage due to repetitive compilation. Doing the test freezes up VS 2013 to the point where you have to kill it using Task Manager. Nothing in the IDE responds to anything after trying to set a breakpoint while the test is running for a while. It seems to get incrementally slower also as the loop runs longer.
```
[TestMethod]
public void TestMethod1()
{
var b = new StringBuilder();
b.AppendLine("using System;");
b.AppendLine("public class Script {");
b.AppendLine(" public int Sum(int a, int b) {");
b.AppendLine(" return a+b;");
b.AppendLine(" }");
b.AppendLine("}");
for (int n = 0; n < 1000000000; n++)
{
dynamic script = CSScript.Evaluator.LoadCode(b.ToString());
int result = script.Sum(10, 20);
}
GC.Collect();
GC.WaitForFullGCComplete(10000);
Console.WriteLine("Done");
}
```
Comments: Indeed dynamic code execution can lead to the memory leaks. Though these leaks are not typical unfreed references (e.g. event handlers) but the assemblies that cannot be unloaded from the AppDomain. This is the fundamental CLR design limitation that was there from the start of .NET. CS-Script doesn't implement its own Evaluator and instead its hosts Mono.CSharp.Evaluator. Your call LoadCode gets redirected immediately to the Mono.CSharp.Evaluator.Compile(). And the memory management is also controlled by Mono. Thus I cannot really give you any solution for the problem as Mono is suffering from the "assembly leaks" the same way as any other framework. Saying that I found that some hosting scenarios engage some sort of caching in Mono runtime and that in turn creates some "leak free" opportunities. However the users reported that these scenarios are not deterministic nor reliable. All this discussed in details here: [http://www.csscript.net/help/evaluator.html](http://www.csscript.net/help/evaluator.html). There is a dedicated section "Limitations". CS-Script downloadables also contain an intesive memory stressing sample _MemoryManagement.cs_ that tests not only yours but other hosting scenarios as well. While "assembly leaking" is a curse that MS already officially refused to fix there is a work around. CS-Script (as opposite to Mono and Roslyn) recognized the problem and provided a built in mechanism for (not assembly) but AppDomain loading/unloading. Though the solution is only possible for the CodeDom hosting model (samples are provided). This is how a typical hosting code looks like: ```C# string asmFile = CSScript.CompileCode("<code>"); using (var helper = new AsmHelper(asmFile, null, true)) { IScript script = helper.CreateAndAlignToInterface<IScript>("*"); script.Hello("Hi there..."); } ``` Note: CodeDom also allows script debugging (Mono doesn't). You will find more details here: [http://www.csscript.net/help/Script_hosting_guideline_.html](http://www.csscript.net/help/Script_hosting_guideline_.html)