Hi ScytaleZero,
First, thank you very much for your positive feedback!
Now, on to your questions:
Most likely it's because invoking a .NET method from script code involves an expensive step (called binding) that maps the method name to a unique method. For an overloaded method this step may require an examination of the argument types, and for a generic method it may require the on-demand construction of the specialized (closed generic) version of the method.
Once a given call signature has been bound successfully, ClearScript caches the binding to speed up subsequent calls. This is very similar to what happens at dynamic call sites emitted by the C# compiler.
If you're concerned about performance and/or wish to restrict the script's activities, then exposing a simple, custom API is probably the best approach. The key for performance is to design your API to minimize hops across the .NET-script boundary, especially if you're using V8. That script engine is remarkably fast but not as fast as JIT-compiled C#, and the overhead of invoking native code from .NET is significant.
Good luck!
First, thank you very much for your positive feedback!
Now, on to your questions:
I noticed that when calling (from .NET) a JavaScript function that talks to .NET objects, it seems to take about an extra 100ms on the first call. Is this because the proxies are set up on demand? Just curious.
Most likely it's because invoking a .NET method from script code involves an expensive step (called binding) that maps the method name to a unique method. For an overloaded method this step may require an examination of the argument types, and for a generic method it may require the on-demand construction of the specialized (closed generic) version of the method.
Once a given call signature has been bound successfully, ClearScript caches the binding to speed up subsequent calls. This is very similar to what happens at dynamic call sites emitted by the C# compiler.
Really this is a specific example of a general question - is it better to do such work on the C# side and expose simpler objects and interfaces to JavaScript?
If you're concerned about performance and/or wish to restrict the script's activities, then exposing a simple, custom API is probably the best approach. The key for performance is to design your API to minimize hops across the .NET-script boundary, especially if you're using V8. That script engine is remarkably fast but not as fast as JIT-compiled C#, and the overhead of invoking native code from .NET is significant.
Good luck!