ChakraCore is the core part of the Chakra Javascript engine that powers Microsoft Edge
Basically if I have a query that looks like
from(array).where(n => n % 2 === 0).select(n => n * 8).reduce((a, n) => a + n, 0);that gets "jitted" to a function which is called to actually run the query
((array, filter0, map1, reducer, acc) => {
for (let i = 0, len = array.length; i < len; ++i) {
value = array[i];
if (!filter0(value)) continue;
value = map1(value);
acc = reducer(acc, value);
}
return acc;
})
The jitted functions are cached so they can be reused whenever the same combination and order of query operators is seen
If I write that function out to a module and
require it in, it's fast. Passing the same exact source code to new Function is slower by a factor of 3-4
As a workaround for now I implemented that query-compilation solution directly in the host (miniSphere) and now my from() queries are super fast :)
(Didn't want the array iteration to be done on the native side since that would be a performance sinkhole)
Following up on the query compiler system I discussed above, I've implemented it and now my built-in from() beats everyone else's functional libraries by a comfortable margin :smile:
const arr = /* 100K random floats between 0-1000 */;
from(arr)
.where(n => n < 500)
.take(100)
.select(n => Math.floor(n))
.plus("rando string")
.shuffle()
.count(it => typeof it);Benchmarking results:
event count time (us) % run avg (us) % avg |
--------------------------------------------------------------------
Underscore _.chain() 1,001 2,398,028 93.7 % 2,395 95.3 % |
Lodash _.chain() 1,001 43,649 1.7 % 43 1.7 % |
from.js 1.0 1,001 38,226 1.5 % 38 1.5 % |
Lazy.js Lazy() 1,001 21,433 0.8 % 21 0.9 % |
from() (mS 5.3+) 1,001 15,326 0.6 % 15 0.6 % |
What would cause MSVC not to be able to find the headers and/or .lib when using the NuGet package?
I've tried everything but can't get it to work. I don't want to keep committing CC binaries to my repo :frowning:
Just checked that it exists in packages/ to make sure, and it does
At one point while fumbling around I got it to find the header... but then it didn't link the .lib so I still couldn't build
e.g. is it in the
references of your projects?
Nothing listed under References at all... which is weird because I also depend on Allegro and that finds the headers and links just fine
No option to add a CC reference...
My packages.config looks like this if it helps
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Allegro" version="5.2.4.0" targetFramework="native" />
<package id="AllegroDeps" version="1.7.0.0" targetFramework="native" />
<package id="Microsoft.ChakraCore.vc140" version="1.11.3" targetFramework="native" developmentDependency="true" />
</packages>
I would have hoped so, but perhaps the .net nuget packages have additional metadata that native ones don't? Or that the one we publish doesn't? To be honest, the nuget packages that we publish are purely for people outside our team, so we have been reactive rather than proactive about it. If you happen to know of a better way to package things, we'll probably make the change :)
It's possible NuGet doesn't like my project setup too... I have the
.sln + all .*proj files in the same directory and MSVC generally seems to prefer one .vcxproj per directory
I used to know what the build.sh option was for this but I’ve forgotten
But I do have a different question. I know ChakraCore will preserve any JsValueRefs that exist on the stack, but I was wondering if this particular case will be safe:
JsValueRef makeobj() {
JsValueRef ref;
ref = JsCreateObject(...);
return ref;
}
void do_stuff() {
JsValueRef objRef = makeobj();
/* ... */
}See, the GC runs off-thread and technically in the above code there may be a small window where the reference doesn't exist on the stack because the stack frame it was created in has been torn down but it also hasn't yet been assigned to the stack variable in the caller. For a short time it only exists in a register, e.g. EAX. Will the GC preserve objects whose only live reference is currently stored in a register?
I guess intuitively it would have to, since stack variables can be completely optimized away by the compiler, but I want to make sure
It should be safe. The GC doesn't interrupt the main thread at arbitrary places for collection (iirc), but instead does so at specific points where it's called directly. The parallel mark thread may miss the reference, but when the in-thread mark and sweep happens it'll find it if it's still live, because it will at that point have been stored to a location on the stack.
If it were possible to trigger GC at arbitrary points, it'd be a matter of having the GC mark also check the saved register memory; for an instance where we put saved registers into memory for the GC to find them, check the bailout code
The GC does most of its work off-thread, but there is a final mark phase that happens in parallel on both the main thread and background threads. this phase rescans any objects that changed during the background mark, as well as stack/register references from the main thread