I think the Java JITs are a better comparison because the workload is more similar: JavaScript is weird for how it’s expected to start in a fraction of a second and soak up a huge bolus of code which may substantially never be used whereas most of the performance-sensitive Python code stabilizes quickly and loads what it uses really early on.

▲

cogman10 8 hours ago | parent [-]

The Java JIT and most other Javascript jits are essentially operating the same way. The core difference is the java language spec sets up a whole bunch of requirements that need to be figured out at startup and are easy to trigger.

For example, static initialization on classes. The JDK has a billion different classes and on startup a not insignificant fraction of those end up getting loaded for all but the simplest applications.

Essentially, Java and the JS jits are both initially running everything interpreted and when a hot method is detected they progressively start spending the time sending those methods and their statistics to more aggressive JIT compilers.

A non-insignificant amount of time is being spent to try and make java start faster and a key portion of that is resolving the class loading problem.

	▲	acdha 3 hours ago \| parent [-]
		Yes, my thought was that the lifecycle is different. The average JVM is probably running for days on average so a huge percentage of the total runtime is in code which had been aggressively optimized by the JIT whereas a lot of JavaScript isn’t used enough to reach that point so their respective developers are going to have different tuning goals. I’d expect Python to be closer to Java in that regard, with some harder to optimize features than Java but less than JavaScript owing to the richer language and better typing.