ChakraCore is the core part of the Chakra Javascript engine that powers Microsoft Edge
Is it normal that functions created using
new Function()have worse runtime performance (by a factor of, it seems, ~3-4x) than an equivalent function defined in the source code? I know eval'd code is slower because it needs to add extra instructions into the bytecode to capture completion values but I wasn't expecting new Function() to be slower too
Probably depends on the function? I just did
var y = 0
function foo() {
var x = 1
var z = y + x
return z
}
var bar = new Function([], `var x = 1
var z = y + x
return z`);
foo();
bar();and looked at the bytecode, and foo and bar were identical. Are you doing more complex things with "arguments" or "super" or anything?
No fancy closures or
arguments or anything, just a basic JS function with a for loop in it
but that wouldn't be the perf of the function, that'd be the perf of compiling the function
hmm
I suppose one other thing is that
new Function'd code is treated in the same way as eval, as dynamic code, while code passed as a script file is treated differently, it may be that the jit treats them differently.
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
