ScriptRunner.Execute performance?

[mikoskinen]

Thanks for the interesting project! We're currently seeing some performance issues with dotnet script and I wonder if we're missing some obvious setting / configuration. Our test script is:

return "hello world";

And the problem is that it takes ScriptRunner.Execute little more than 1 second to execute this, even if we execute the same script multiple times using the same ScriptRunner instance. The performance doesn't change from first execution to second or third execution. It feels like we're missing some "cache" toggle.

This is how we are initializing things:

            var runtimeDependencyResolver = new RuntimeDependencyResolver(logFactory);
            var compiler = new ScriptCompiler(logFactory, runtimeDependencyResolver);
            var runner = new ScriptRunner(compiler, logFactory, ScriptConsole.Default);

            var sourceText = SourceText.From(code);
            var context = new ScriptContext(sourceText, currentWorkingDirectory ?? Directory.GetCurrentDirectory(), args, null, OptimizationLevel.Release, ScriptMode.Eval, packageSources: packageSources);

            runner.Execute<string>(context);

Any ideas how we could make things faster? It's OK if ScriptRunner.Execute takes second or so for the first time but we would like things to be much quicker when we run the same script the second time.

[seesharper]

Hi Mikael.

We are aware of the performance issue and there is actually several things we can do to improve on this. For instance, for every run we do a package restore behind the scenes to bring in the script dependencies. This is done in a separate process (we basically just wrap dotnet restore) and that alone adds a second to the overall execution. We could look at the dependencies gathered from the script file(s) and decide not to do a dotnet restore in the case where nothing has changed. Deciding if nothing has changed is pretty easy apart from the case where you have dependencies with no specific version. In that case we would always have to do a dotnet restore since there could be newer package versions since the last time we did a restore. But given that the script declares packag e references that includes the package version, we could implement a cache over this. That is probably the feature that would impact performance the most.

Note that we also have an option to "publish" your script that basically turns you script into an executable

dotnet script publish 

[filipw]

There is a possibility to "cache" a script for subsequent quick runs but it is only available in the executable, not in the library layer. It's described here https://github.com/filipw/dotnet-script/releases/tag/0.26.0

However, I think it could be moved to the library so that it would kick in when invoking the script programmatically.

[tomlm]

see PR #339 , this should give some improvements.

[tomlm]

This PR was accepted, the essence is that the DLLs produced by executing a script are automatically cached if the source script has not changed.

[seesharper]

Closed by #383