3 ms·
Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. The nondeterminism can come from lots o
by pizlonator 7y ago
Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior.
The nondeterminism can come from lots of places. In JSC it’s that the JIT polls the heap for some of its profiling and it profiles concurrently. So OS scheduling decisions affect what types the JIT sees.
- saagarjha 7y ago> Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. All all JavaScript JITs this way?
- pizlonator 7y agoAll the good ones. In all seriousness, I think I heard that FF doesn’t profile concurrently. Maybe that’s one of the reasons why they’re so slow.
- bjourne 7y agoPerformance in general is non-deterministic in a multi-tasking os because you have multiple processes competing for cpu time. My point is that there is nothing inherent to Javascript VMs that makes them harder to control or analyze. Runtimes for other dynamic languages and database engines shows that proper tooling makes it much easier for developers to optimize for performance.
- pizlonator 7y agoOn some level of course that’s true but surely you’re not suggesting that the nondeterminism of JS is no worse than the nondeterminism of C. C at least runs with the same types every time.
- dragonwriter 7y agoC is weakly typed, so that it runs with the same static types means very little.
- pizlonator 7y agoC has strong types for the purpose of optimization. A C compiler never wonders whether + means int addition or string concatenation for example. In JS the optimizing compiler doesn’t get such type information except by profiling and profiling is nondeterministic.