Performance profile of the Javascript port

[ddyer0]

I meter cpu oriented performance to tune the behavior of my game playing robots. My rough measurement of
performance rates a regular desktop app at 1.3 standard cpus. Android and IOS apps rate 0.3-0.4 standard CPUs.
Javascript apps (on a standard desktop) 0.3-0.4 standard cpus.

This seemed like good news, but actual measurement of robots put their performance about 50x worse.
That's a pretty big gap, so clearly my rough measure isn't working for this case.

(1) from first principles and general familiarity with how the javascript code is structured, what is
the likely reason for the difference?
(2) how can I get actual data instead of guesses.

[shai-almog]

This was improved a bit in 7.0.281 but overall JavaScript is DEEPLY problematic in terms of performance due to many limitations most of which are its restricted type system. E.g. long isn't a type that's available in JavaScript and we end up with a rather complex hack to get it working. In a recent optimization we treat numbers differently based on their size but this means branching on every operation.

If you have specific benchmark code that performs poorly then post it. It might be a small change you can do that would boost performance significantly or might be something we can improve.

We're considering an ASM version of the JavaScript port too, but I'm not sure if that would give us the desired performance boost.

[ddyer0]

I did a little research and I'm shocked to find that there's no good metering framework for javascript -- and anyway, if it existed
the conceptual distance between what javascript is literally doing and what java code I ordinally wrote is hard to bridge. So I wrote
a simple profiler and installed it manually in the main path for robot searches. Here's a perliminary result.

// microsecond samples (windows)
Make_Move 3188137
Random_Move 3098176
Unmake_Move 1098240
normalizedScore 30887
simUsingTree 11270
unwindAndScore 7099
copyTheBoardNow 4709
runSimulation 2026
List_Of_Legal_Moves 1190
expandLeafNode 579
getNewChildren 230

// microsecond samples (javascript)
Top 20 functions
Random_Move 112953
Make_Move 45018
Unmake_Move 31676
yield in run 1449
expandLeafNode 270
simUsingTree 210
normalizedScore 167
copyTheBoardNow 139
List_Of_Legal_Moves 125
unwindAndScore 118
runSimulation 92
getNewChildren 27

The most interesting thing here is that "random move" went from rough parity with make-move to being 2.5x
as expensive. This gives me a target to continue drilling. Note that I don't use the system random number
generator, but a clone - because I have to generate the same random sequences on all platforms.

This mode of metering (and some variants) would be easy to insert into the code generation - basically requires
an extra function call at the exit of functions - so it could be available on a switch that put it everywhere without
code modifications. I'll start a separate discussion for that.

[shai-almog]

If you include the Java code of the random move it might be something we can help you with. Random sounds like a problematic operation that would hit the edge cases of our numeric limits repeatedly. I'm guessing you shift and roll numbers which would trigger MSB changes to long. That's hard to do correctly in JavaScript and even harder to do it in a performant way.