Update posted here.
New Post: Culture of Windows Script Engine
↧
↧
New Post: Correct ClearScript Cleanup
I have been using ClearScript in a Project for a while and have been using a simple cleanup operation of "engine.Dispose(); engine = null;"
Looking at your included "ClearScriptConsole" I notice you have a "using { }" and that is all.
So my question is what is the correct method to ensure all resources are Cleaned Up so that if I create the ClearScript engine several times I am not consuming resources.
My question stems from the assumption that I am doing something wrong as each iteration of the ClearScript engine that I execute results in a different engine.name value
eg 5 different calls of my "using { }" version of calling engine.Execute resulted in this below and I got the same using Dispose and also when adding GarbageCleanup(true).
Engine Name : V8ScriptEngine
Engine Name : V8ScriptEngine [2]
Engine Name : V8ScriptEngine [3]
Engine Name : V8ScriptEngine [4]
Engine Name : V8ScriptEngine [5]
Looking at your included "ClearScriptConsole" I notice you have a "using { }" and that is all.
So my question is what is the correct method to ensure all resources are Cleaned Up so that if I create the ClearScript engine several times I am not consuming resources.
My question stems from the assumption that I am doing something wrong as each iteration of the ClearScript engine that I execute results in a different engine.name value
eg 5 different calls of my "using { }" version of calling engine.Execute resulted in this below and I got the same using Dispose and also when adding GarbageCleanup(true).
Engine Name : V8ScriptEngine
Engine Name : V8ScriptEngine [2]
Engine Name : V8ScriptEngine [3]
Engine Name : V8ScriptEngine [4]
Engine Name : V8ScriptEngine [5]
↧
New Post: Correct ClearScript Cleanup
Hi egooner,
Calling the
As for engine names, "V8ScriptEngine [5]" refers to the fifth engine you've constructed with the name "V8ScriptEngine" during the current process's lifetime. It doesn't mean that there are five script engines currently active.
Cheers!
Calling the
Dispose() method - either directly or via the using statement - is sufficient. If you don't do that, .NET's garbage collector will eventually take care of it, but it may take a long time.As for engine names, "V8ScriptEngine [5]" refers to the fifth engine you've constructed with the name "V8ScriptEngine" during the current process's lifetime. It doesn't mean that there are five script engines currently active.
Cheers!
↧
New Post: Correct ClearScript Cleanup
Thanks for the feedback. I had hoped this was the case but was concerned that there is clearly tracking of the different instances having been created between NEW Engines telling me something was still around.
↧
New Post: ClearScript on Mono/Xamarin?
I was hoping to use ClearScript for adding JavaScript to a game written with MonoGame. Is there any chance that you could release a portable version which includes the V8 engine?
What are the challenges involved? It looks like it would be a significant undertaking, and perhaps there's better hope for an IL-only JS engine (maybe Jurassic would be easier).
ClearScript is fantastic, by the way :)
What are the challenges involved? It looks like it would be a significant undertaking, and perhaps there's better hope for an IL-only JS engine (maybe Jurassic would be easier).
ClearScript is fantastic, by the way :)
↧
↧
New Post: ClearScript on Mono/Xamarin?
Hello reubenbond!
Unfortunately Mono doesn't support mixed-mode assemblies such as ClearScript's V8 interface (ClearScriptV8-*.dll). We'd like to redesign that layer eventually, but that effort is not currently planned. ClearScript also depends heavily on the C# Runtime Binder, an API that Mono doesn't seem to support.
Have a look at Jurassic, Jint, and V8.NET. And thank you for your kind words!
Unfortunately Mono doesn't support mixed-mode assemblies such as ClearScript's V8 interface (ClearScriptV8-*.dll). We'd like to redesign that layer eventually, but that effort is not currently planned. ClearScript also depends heavily on the C# Runtime Binder, an API that Mono doesn't seem to support.
Have a look at Jurassic, Jint, and V8.NET. And thank you for your kind words!
↧
New Post: ScriptItem performance
I noticed some performance issues with the usage of ScriptItem.
What I did was I had a constructor which received a script item as argument. And because ScriptItem has accessors set to internal, I had to use it as DynamicObject or dynamic.
What I wanted was to create a flat table of the object, just by getting the object keys as column name and their values as row values. The Properties are retrieved with the "GetDynamicMemberNames()" function, so no problems there. But for each of the properties I needed to create a Binder and get the value (see code below)
Now anybody can guess that this is not very fast. I tried to create a simple table with 3 rows and 13 columns. And it took a good +/- 1500 milliseconds on one run. I did the same with JSON.net JObject and because accessing properties isn't such a hassle their I got a performance of 0 milliseconds on one run. My temporary fix is that I call JSON.stringify before the constructor and in the constructor I uses JSON.NET his parser.
Anyway, my question or point of discussion: Isn't ScriptItem flawed by design? Why the use of dynamics? Take a look at how JSON.net encodes JS objects with strict types. In essence are all JS Objects KeyValuePairs where the Value types can vary.
Or am I doing something terrible wrong?
What I did was I had a constructor which received a script item as argument. And because ScriptItem has accessors set to internal, I had to use it as DynamicObject or dynamic.
What I wanted was to create a flat table of the object, just by getting the object keys as column name and their values as row values. The Properties are retrieved with the "GetDynamicMemberNames()" function, so no problems there. But for each of the properties I needed to create a Binder and get the value (see code below)
Now anybody can guess that this is not very fast. I tried to create a simple table with 3 rows and 13 columns. And it took a good +/- 1500 milliseconds on one run. I did the same with JSON.net JObject and because accessing properties isn't such a hassle their I got a performance of 0 milliseconds on one run. My temporary fix is that I call JSON.stringify before the constructor and in the constructor I uses JSON.NET his parser.
Anyway, my question or point of discussion: Isn't ScriptItem flawed by design? Why the use of dynamics? Take a look at how JSON.net encodes JS objects with strict types. In essence are all JS Objects KeyValuePairs where the Value types can vary.
Or am I doing something terrible wrong?
publicvoid ParseDynamic(DynamicObject o) { var props = o.GetDynamicMemberNames(); bool isArray = true; // try cast to inttry { foreach (var k in props) { Int32.Parse(k); } } catch { isArray = false; } if (!isArray) AddRow(o); else { foreach (var k in props) { AddRow((DynamicObject)GetMember(o, k)); } } } privatevoid AddRow(DynamicObject obj) { var cols = obj.GetDynamicMemberNames(); var row = new MiDataRow(this); rows.Add(row); // Add all columnsforeach (var col in cols) { if (!columns.Contains(col)) { columns.Add(col); ResizeRows(); } row[col] = GetMember(obj, col).ToString(); } } privatestaticobject GetMember(DynamicObject o, string propName) { var binder = Binder.GetMember(CSharpBinderFlags.None, propName, o.GetType(), new List<CSharpArgumentInfo>{ CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null)}); var callsite = CallSite<Func<CallSite, object, object>>.Create(binder); return callsite.Target(callsite, o); }
↧
New Post: ScriptItem performance
Hi blackshade,
.NET's dynamic infrastructure provides a convenient way to access script objects in a way that's both .NET-friendly and engine-neutral. A dictionary-style interface might also be convenient, but it's not clear what advantage it would have over the combination of
The problem with your
This implementation is simpler and takes advantage of inline caching to speed up repeated calls. In our experiments it's about 22x faster on average in Release builds.
Still, using JSON tunneling as you suggest makes sense in many cases. ClearScript provides live access to script objects, but if all you need is a snapshot, then JSON is a great way to minimize marshaling and improve performance.
Thanks for your question, and good luck!
Why the use of dynamics?
.NET's dynamic infrastructure provides a convenient way to access script objects in a way that's both .NET-friendly and engine-neutral. A dictionary-style interface might also be convenient, but it's not clear what advantage it would have over the combination of
GetDynamicMemberNames() and dynamic indexing.The problem with your
GetMember() method is that it recreates the binder and callsite each time. Try this instead:privatestaticobject GetMember(object o, string propName) { return ((dynamic)o)[propName]; }
Still, using JSON tunneling as you suggest makes sense in many cases. ClearScript provides live access to script objects, but if all you need is a snapshot, then JSON is a great way to minimize marshaling and improve performance.
Thanks for your question, and good luck!
↧
New Post: ScriptItem performance
Thank you for the reply.
I will try and benchmark your suggestion and post the results below.
I will try and benchmark your suggestion and post the results below.
↧
↧
New Post: ScriptItem performance
Ok thanks!
It is still +/- 60 milliseconds (ScriptItem) against +/- 3 milliseconds (String -> Json.net) on the initial run. But after that the JIT has optimized both to nano seconds.
So thanks! These differences can be explained by the fact that on the first run the JIT will optimize a part of the code path the seconds also takes.
I will look more into it and do some better benchmarks to see which one is really faster. Still I expect that the String version is faster.
If that is the cast that really is such a shame.
But more on this later, thanks anyway!
It is still +/- 60 milliseconds (ScriptItem) against +/- 3 milliseconds (String -> Json.net) on the initial run. But after that the JIT has optimized both to nano seconds.
So thanks! These differences can be explained by the fact that on the first run the JIT will optimize a part of the code path the seconds also takes.
I will look more into it and do some better benchmarks to see which one is really faster. Still I expect that the String version is faster.
If that is the cast that really is such a shame.
But more on this later, thanks anyway!
↧
New Post: ScriptItem performance
Ok I did some more benchmarking and I did the following, where rec is a flat json object.
Both the strJson and the JSON function implement the same idea, but the strJson de-serialises the string, and still managed to be faster.
My point stays, isn't it better to not make ScriptItem dynamic. Because within Javascript all object can be of fixed types and all objects are key value pairs anyway. Or maybe is it possible to make use of JSON.net JObject instead of dynamic ScriptItem? Even translating the ScriptItem to JObject results in a higher benchmark than the above benchmark.
Anyway, thanks for your time and I hope you can do something with my findings.
var arr = [rec, rec, rec]; var strJson = JSON.stringify(arr); new MiTable("form", arr); new MiTable("form", strJson); startTime(); for (var i = 0; i < 1000; i++) new MiTable("form", strJson); stopTime(); startTime(); for (var i = 0; i < 1000; i++) new MiTable("form", arr); stopTime();
My point stays, isn't it better to not make ScriptItem dynamic. Because within Javascript all object can be of fixed types and all objects are key value pairs anyway. Or maybe is it possible to make use of JSON.net JObject instead of dynamic ScriptItem? Even translating the ScriptItem to JObject results in a higher benchmark than the above benchmark.
Anyway, thanks for your time and I hope you can do something with my findings.
↧
New Post: ScriptItem performance
Hi blackshade,
The purpose of a script item in ClearScript is to allow .NET code to access an actual "live" script object, as opposed to a serialized copy of its data.
Yes, it's definitely faster to read data from a managed collection such as a Json.NET
However, this is very different from what script items do. Some examples:
The purpose of a script item in ClearScript is to allow .NET code to access an actual "live" script object, as opposed to a serialized copy of its data.
Yes, it's definitely faster to read data from a managed collection such as a Json.NET
JObject or a standard .NET dictionary - and if reading a script object's properties quickly is what you need to do, then we encourage and recommend JSON tunneling. Hopping the boundary between the managed and script environments is expensive, and JSON lets you transfer an entire object's data in one hop.However, this is very different from what script items do. Some examples:
- Writing to a script item modifies the actual script object to which it's bound.
- Unlike JSON, script items provide access to JavaScript properties that are not enumerable.
- Script items invoke property getters and setters as necessary.
- Script items that are functions can be invoked to execute script code.
-
Script items provide access to script objects that aren't JSON-friendly (e.g., VBScript objects).
↧
New Post: ScriptItem performance
Hi,
Ahh I see, I thought you would only get a snapshot of the given script item. But if you would run the script async of the c# code, the changes in scriptitem would be live.
I didn't think about that. The structure of the ScriptItem makes a whole lot of more sense to me now.
Thank you again sir! I will stick to my JSON tunneling because that is what I need.
If I haven't said so: Nice work on this project, love it.
Ahh I see, I thought you would only get a snapshot of the given script item. But if you would run the script async of the c# code, the changes in scriptitem would be live.
I didn't think about that. The structure of the ScriptItem makes a whole lot of more sense to me now.
Thank you again sir! I will stick to my JSON tunneling because that is what I need.
If I haven't said so: Nice work on this project, love it.
↧
↧
New Post: ClearScript on Mono/Xamarin?
Hi, I'm also looking to use this cross platform and have been looking at alternatives for a while, but so far Clearscript is the only one that does things the way I want it to. It was a real bummer when I noticed it only worked on Windows.
How does V8.NET do it, since their library works on other platforms? What are they doing different?
I was going to compare to see if I could make the clearscript v8 work with v8.net's implementation, but my lack of c++ knowledge would be like climbing a mountain for me.
I really hope that you'll make it work cross platform soon!
How does V8.NET do it, since their library works on other platforms? What are they doing different?
I was going to compare to see if I could make the clearscript v8 work with v8.net's implementation, but my lack of c++ knowledge would be like climbing a mountain for me.
I really hope that you'll make it work cross platform soon!
↧
New Post: ScriptItem performance
Thanks for your feedback!
↧
New Post: ClearScript on Mono/Xamarin?
Hi Cadavre,
The difference has to do with the way these projects interface managed code with native code. Our understanding is that V8.NET uses P/Invoke with the managed and native sides residing in separate assemblies, whereas ClearScript uses mixed-mode assemblies that house both managed and native code.
Mono doesn't support mixed-mode assemblies on non-Windows platforms, and unfortunately this isn't just a matter of binary packaging. It affects how the marshaling code is written, and this is why creating a Mono-friendly version of ClearScript is not a trivial task.
Another issue for ClearScript is its reliance on the C# Runtime Binder, an API that Mono doesn't seem to support, although it does have other APIs that might provide a suitable alternative.
Cheers!
How does V8.NET do it, since their library works on other platforms? What are they doing different?
The difference has to do with the way these projects interface managed code with native code. Our understanding is that V8.NET uses P/Invoke with the managed and native sides residing in separate assemblies, whereas ClearScript uses mixed-mode assemblies that house both managed and native code.
Mono doesn't support mixed-mode assemblies on non-Windows platforms, and unfortunately this isn't just a matter of binary packaging. It affects how the marshaling code is written, and this is why creating a Mono-friendly version of ClearScript is not a trivial task.
Another issue for ClearScript is its reliance on the C# Runtime Binder, an API that Mono doesn't seem to support, although it does have other APIs that might provide a suitable alternative.
Cheers!
↧
New Post: ClearScript on Mono/Xamarin?
Thanks for the quick response! I hope you will eventually make it work cross platform, ClearScript is really good!
↧
↧
New Post: ClearScript on Mono/Xamarin?
By the way, I stumbled upon this thing called swig (http://www.swig.org/) while looking into using RakNet.
Quote from the RakNet documentation:
Quote from the RakNet documentation:
What is Swig?Could this be of any use?
Swig is an application that generates wrapper code for a native DLL to interface with other languages allowing you to use a C/C++ library in one of the supported languages. Currently Swig configuration for RakNet is set up to generate a managed interface that can be used in managed C# in Windows, as well as in Linux with Mono.
Swig generates a CXX and .h file, which exposes interfaces that can be used by the target language. The CXX file is included when building the C++ dll that the target language uses.
Swig also generates files in the target language for inclusion in the project of the target language to interface with the dll. These are added to the project of the target language.
↧
New Post: ClearScript on Mono/Xamarin?
Thanks Cadavre! We'll take a look, but the issue isn't interop as much as it is the redesign and re-implementation of the ClearScriptV8 layer.
↧
New Post: ClearScript on Mono/Xamarin?
Yeah, okay, but it might still be useful! :)
↧
More Pages to Explore .....
