3 ms·

In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

by ruuda 29d ago

a022311 29d ago
I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.
preg_match 28d ago
The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming. It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up. That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
- kccqzy 28d ago
  I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
  - gsnedders 28d ago
    This hasn’t been true in over a decade.
  - acchow 28d ago
    Chrome on iOS has always been JIT'd because it used a WKWebView. It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago. I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
- cageface 28d ago
  Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
  - preg_match 27d ago
    Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless https://v8.dev/blog/jitless In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%. This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM. Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit https://wiki.php.net/rfc/jit We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
- pjmlp 26d ago
  That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains. The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
  - preg_match 25d ago
    You’re correct, where I got confused is the lazy per-method JIT and the tiers of JIT optimization. My understanding is that dotnet only compiles on first function call, or when it has to for things like generics. So, some code is never compiled if it’s never executed. And then, functions will be re-JIT at higher optimization levels under certain conditions later. You certainly know more about this than me, but yes I was wrong about conditional JIT.

In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

by ruuda 29d ago

In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

a022311 29d ago

I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.

preg_match 28d ago

The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming. It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up. That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.

kccqzy 28d ago
I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
- gsnedders 28d ago
  This hasn’t been true in over a decade.
- acchow 28d ago
  Chrome on iOS has always been JIT'd because it used a WKWebView. It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago. I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
cageface 28d ago
Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
- preg_match 27d ago
  Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless https://v8.dev/blog/jitless In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%. This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM. Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit https://wiki.php.net/rfc/jit We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
pjmlp 26d ago
That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains. The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
- preg_match 25d ago
  You’re correct, where I got confused is the lazy per-method JIT and the tiers of JIT optimization. My understanding is that dotnet only compiles on first function call, or when it has to for things like generics. So, some code is never compiled if it’s never executed. And then, functions will be re-JIT at higher optimization levels under certain conditions later. You certainly know more about this than me, but yes I was wrong about conditional JIT.