Performance, metrics and flattening imports

[PeterWone]

The way I develop for JINT exploits VS Code and node to get debug, and I have a custom pipeline that resolves import statements as the files they reference, with recursive descent and a name table to prevent duplication. There's some scrubbing to get rid of export keywords. If you called it a linker you wouldn't be wrong.

It works pretty well, and while it won't help you with direct or indirect dependencies on node, it does make it easy to organise code while developing it.

As a result it is now convenient to run the same code on node or JINT and gather metrics, and I notice that the same code is about forty times faster on node. Is any of this stuff interesting to people working on JINT? I could package the toolchain, perhaps as a VS Code extension.

[lahma]

Node (V8) compiles code while Jint is an interpreter so there will always a be a large performance difference based on that. There has been some discussion whether Jint should do some sort of tiered compilation when something is deemed as "hot".

Of course if you can pinpoint a specific place in Jint that could be improved, say, you have use case where you call specific JS function (like Math.min, can be anything), do a spread/rest operation or something that really pops out in the trace as hot/odd.

[lahma]

I converted this to a conversation as there's not tangible work item(s) yet.

[cyraid]

Something ChowJS did AOT (closed source unfortunately). I'd love to see an AOT approach where you can compile into either an IL ByteCode, or Native Binary (specify cpu). It's obviously a HUGE undertaking as designing a VM for the IL is no trivial task (as each IL instruction would map to optimized assembly I'm sure). Sure you could do what Jurassic / YantraJS does and use System.Reflection.Emit to generate dynamic C# IL, but it's not compatible with NativeAOT.