After prototyping and testing ClearScript, it turns out not to be a good fit for us. Thinking about it, I realize it should have been obvious to me that the goals of the project are far different from our scenario. Neither is good or bad, just different.
Just to document this for others: If you don't pass in any parameters nor make any calls back to .Net from JS, ClearScript using V8 is much faster while in JS land, twice as fast as IronJS in my simple tests. I'm sure it would be even faster if you were using even moderately complicated JS code. This is a great scenario for using ClearScript!
However our object model deals with very large datasets with very complex behavior. It is entirely impractical to "lob objects" across the V8 boundary to JS. That means we end up with a lot of calls being proxied back and forth between .Net and V8. That would be bad enough but the behavior of dynamic is also slow and the primary use for me is getting a delegate out that will invoke some JS when called, meaning every invocation goes through dynamic; in some cases I can be making this transition millions of times, and the average JS script itself probably makes 20-50 calls back into .Net, so the total boundary transitions are a quarter of a billion in the worst case. (Basically I tell my customers: "this is what your JS script looks like: function theScript(param1, param2, param3, param4, param5) { }; fill in the body and return me an [Array, string, number, bool]", then I invoke theScript() where required, except there may be dozens or hundreds of these for various scenarios.)
I tried various schemes and benchmarked against IronJS and IronJS was just way faster - by an order of magnitude or even multiple orders of magnitude in some cases. I tried pre-registering my object type and using attributes to control the proxying behavior (to avoid the reflection hit on every call) but it just couldn't get close to closing the gap. The more .Net objects I pass in to the JS function, the worse the gap. The more calls JS makes back to .Net, the worse the gap.
To use V8 and do what I want to do would require a different approach, one that allowed fast function calls between the two worlds, and that allowed me to pre-register all types during setup so there is no reflection and no use of dynamic. Obviously that is far different from the goals of the ClearScript project!
I do want to say thank-you to whoever the anonymous Microsoft-ians are who work on this project. It is much appreciated, even though it isn't useful for my scenario.
Side note: I wish Microsoft would put some resources into making JS a first-class citizen for these scenarios. If I want to host a JS runtime and compile JS into "native" methods for that platform, on Java I have Rhino/Nashorn that "compile" JS into JVM byte code (Nashorn is very much like IronJS actually). On iOS/Mac, I have JavaScriptCore, though Objective-C is native already. But for .Net environments, there aren't any good options and none supported, even in the form of open-source funding. Unfortunately the IronJS project is dead since Fredrik hasn't been making commits in over a year; can't blame him, working for free after all! I may have to block out some time to learn F# and work on it.
Just to document this for others: If you don't pass in any parameters nor make any calls back to .Net from JS, ClearScript using V8 is much faster while in JS land, twice as fast as IronJS in my simple tests. I'm sure it would be even faster if you were using even moderately complicated JS code. This is a great scenario for using ClearScript!
However our object model deals with very large datasets with very complex behavior. It is entirely impractical to "lob objects" across the V8 boundary to JS. That means we end up with a lot of calls being proxied back and forth between .Net and V8. That would be bad enough but the behavior of dynamic is also slow and the primary use for me is getting a delegate out that will invoke some JS when called, meaning every invocation goes through dynamic; in some cases I can be making this transition millions of times, and the average JS script itself probably makes 20-50 calls back into .Net, so the total boundary transitions are a quarter of a billion in the worst case. (Basically I tell my customers: "this is what your JS script looks like: function theScript(param1, param2, param3, param4, param5) { }; fill in the body and return me an [Array, string, number, bool]", then I invoke theScript() where required, except there may be dozens or hundreds of these for various scenarios.)
I tried various schemes and benchmarked against IronJS and IronJS was just way faster - by an order of magnitude or even multiple orders of magnitude in some cases. I tried pre-registering my object type and using attributes to control the proxying behavior (to avoid the reflection hit on every call) but it just couldn't get close to closing the gap. The more .Net objects I pass in to the JS function, the worse the gap. The more calls JS makes back to .Net, the worse the gap.
To use V8 and do what I want to do would require a different approach, one that allowed fast function calls between the two worlds, and that allowed me to pre-register all types during setup so there is no reflection and no use of dynamic. Obviously that is far different from the goals of the ClearScript project!
I do want to say thank-you to whoever the anonymous Microsoft-ians are who work on this project. It is much appreciated, even though it isn't useful for my scenario.
Side note: I wish Microsoft would put some resources into making JS a first-class citizen for these scenarios. If I want to host a JS runtime and compile JS into "native" methods for that platform, on Java I have Rhino/Nashorn that "compile" JS into JVM byte code (Nashorn is very much like IronJS actually). On iOS/Mac, I have JavaScriptCore, though Objective-C is native already. But for .Net environments, there aren't any good options and none supported, even in the form of open-source funding. Unfortunately the IronJS project is dead since Fredrik hasn't been making commits in over a year; can't blame him, working for free after all! I may have to block out some time to learn F# and work on it.
