Hi again,
OK, well, you could start by pre-executing a simple script such as
That sounds even better!
For all performance-sensitive applications that use ClearScript with V8, we recommend that you (a) use the latest version of ClearScript (currently 5.4.0), (b) disable the GlobalMembers feature by using
Good luck!
And so when I try to execute jQuery followed by the SignalR script it fails because jQuery references the window object from the web API provided by the browser.
OK, well, you could start by pre-executing a simple script such as
window = this
to provide a window
alias for the global object. Then run the jQuery/SignalR script again to see what else it needs. If it really does need the HTML DOM, you might be out of luck, but if it only needs a tiny subset, you might be able to accommodate it by providing a handful of simple mock objects.
I think I have found an alternate solution. I created my own .NET class that handles the client side SignalR interface. I then add this type to the V8 engine. The JavaScript then interfaces with SignalR through my .NET host environment.
That sounds even better!
I'm curious to see how well it performs when it is loaded up with 10 scripts and a thousand SignalR data subscriptions. Is there anything you can think of that I should look out for?
For all performance-sensitive applications that use ClearScript with V8, we recommend that you (a) use the latest version of ClearScript (currently 5.4.0), (b) disable the GlobalMembers feature by using
V8ScriptEngineFlags.DisableGlobalMembers
(unless you really need it), and (c) compensate for V8's lazy garbage collector by calling ScriptEngine.CollectGarbage()
once in a while (e.g., periodically or when your application is idle).Good luck!