Specially if the JIT can reuse PGO from previous execution runs like MGO on .NET 4.5+ or Android 7.
https://blogs.msdn.microsoft.com/dotnet/2012/03/20/improving...
> In general, we're happy to pay compile time to get peak throughput.
Shouldn't a program which runs a UI (which WebKit basically is) optimize for lowest latency instead?
Do you want to achieve low latency with low latency, or do you want low latency and it's so important that you don't mind high latency to get it :)
What I mean is yes people want lowest latency. But you can either compile quickly, to get to a reasonably low latency when using the app and to get to that point itself with low latency, or you can compile with optimisations, and get lower latency when the compilation is done but have to wait with high latency to get to that point.
Both approaches are 'optimising for latency' so you'd need to be more specific.
The practical compromise is tiers of compilation, each taking higher latency to apply but producing lower latency when they're done.
Note that this is only the third (top) tier JIT (or fourth if you include the interpreter). By that point, you're really optimising for throughput and not compile time.
WebKit used LLVM as its optimizing JIT compiler for a couple years, and it was fine. We only switched away from LLVM when we wrote a compiler that generated code that was as good as LLVM (for our narrow use case) but in less compile time; we would probably switch back to LLVM (or any other heavy AOT-style compiler) if it gave us more throughput than our current compiler. In general, we're happy to pay compile time to get peak throughput.
The reason why we have this attitude is that we have more than one JIT. WebKit has three JIT tiers for JS and two for WebAssembly. The top tier does crazy expensive optimizations (the most expensive of which is a must-points-to analysis for removing object allocations; in second place is the Yorktown-style regalloc) and has long compile times, but it's OK because by the time we run it, we've already done a pretty good job of optimizing the code with the JIT tier just below the top one. The second-to-top JIT tier in WebKit, called the DFG JIT, runs very quickly.
Overall this is a great post! I just think that there is even more potential for perf with JITs than what the post implies.