I have had my eyes on this project over the years trying it out here or there; however, I recently have a requirement for scripting services in a production environment. Thus, I have investigated the current state of the project.

I like the idea of C# scripting; however, I am not so sure about the implementation of this project in that I feel like there is a ton of performance being left on the table for cached startup time.

After caching and performing some simple hello world runs, the results I get for execution time are shown below: 400 - 500ms to execute the script. I am doing the simplest / dumbest stopwatch timing, so please advise if the method is too crude for benchmarking.

I have checked out the code and debugged through it to find many areas taking in excess tens to hundreds of milliseconds of execution time and I am not sure I understand the design decisions. The biggest time sink I can find is when the dependencies are resolved on each run of the script. This takes hundreds of milliseconds and seems to be the major culprit.

1. I don't understand the decision to use hashes to check if the scripts have changed. I am familiar with build systems and while hashing is the 'precise' solution, many projects get by perfectly fine using file timestamps. Hashing is the slow solution.
2. It seems like the project is generating real asset and project files behind the scenes as the "implementation detail". The dependency resolution which runs on each script execution seems to be taking a long time. I would think that instead of implementing this heavy handed mechanism, you would simply create a simple, single file, like a database that stores all the script file paths and their timestamps. You then load this tiny file in memory and query to see if each file exists where its supposed to and its current timestamp. If there is a mismatch, you can trigger a rebuild. I see this taking tens of milliseconds, not an order of magnitude more like the current solution.

Doing some basic benchmarking with the codebase I figure that the 'cached' path of script execution could be reduced very significantly with a different implementation. 500ms startup time in the 'cached' path is not acceptable for our application. I mean, I get it. At the end of the day, the scripts are compiled down to assemblies and ran. There should be no performance difference once the scripts are executed. However, remember we are talking about scripts here. In general, scripts may not be full programs. What sense does it make to tell me that dotnet-script runs scripts 'blazingly fast' when my script takes milliseconds to execute but 500ms to start up?... Then my runtime is 500ms+ on a script that would run in 5ms as a console application. I think the big picture has been missed here in that regard.

Please understand that the numbers I am giving are for my relatively modern high end system. The absolute values of the performance numbers don't matter much, but its the relative order of magnitude of the numbers that does matter. Nobody is saying that the 'cached' path startup time has to be perfect; however, I do believe it can be very significantly better.

Also, if there is something I am doing incorrectly to get these numbers or an incorrect setting, kindly point me in the right direction.

Just my $0.02. I would rather post here to see if there are any bites to my comments instead of jumping to roll our own solution.