733208 - sql.js with inlining much slower than without

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Alon Zakai (:azakai)]

Attachment: benchmark with and without inlining

sql.js is SQLite compiled to JavaScript. When compiled with inlining enabled in LLVM, it becomes much slower (3x or so), which is surprising as normally inlining makes code faster (aside from removing function call overhead, it enables LLVM to do a better job at optimizing). Inlining does create much larger functions, so possibility this is a function recompilation issue?

Attached is a sql.js benchmark with and without inlining.

Comment 1

[Alon Zakai (:azakai)]

Forgot to say, without inlining sql.js is 20x slower than native code, which is worrying.

Comment 2

[Brian Hackett [Laid off!]]

Do you have comparable benchmarks that work in the shell?

Comment 3

[Alon Zakai (:azakai)]

To make these run in the shell, just remove the first 30 lines, up to

  // The compiled code

and remove the last 3 lines of HTML that close the script tag etc. That leaves just the compiled code.

Comment 4

[Mayank Bansal]

I did a Nightly vs Chrome comparison (jnstead of the original idea of "noinline" vs "inline" on Firefox). Here are the results:

"Benchmark"
Nightly: https://share.firefox.dev/3wyHaJi (7s)
Chrome: https://share.firefox.dev/3SU4nx5 (4.4s)

"Benchmark-noinline"
Nightly: https://share.firefox.dev/49OMqXr (2.8s)
Chrome: https://share.firefox.dev/3TfBXyW (1.5s)

Nightly is ~2x slower in both cases, and spends majority of time in Baseline. So my guess is the testcases must be doing something that is not recommended anymore.

:iain : Worthwhile to investigate here, or should we just close this as INCOMPLETE?

Comment 5

[Mayank Bansal]

FWIW, both the testcases print the timings of their benchamrking. For each, the major difference is in "Insert" operation :

benchamrk-noinline - Nightly: Chrome :: 1098ms:319ms
benchmark - Nightly: Chrome ::4432ms:1417ms

Comment 6

[Iain Ireland [:iain]]

This code was created via Emscripten, which generally targets JS features that are well supported. I suspect that the actual problem is that the functions being created are over the Ion size limit. Taking a quick peek with IONFLAGS=aborts, I see three aborted compilations with inlining, and one without inlining.

I'm not aware of real webpages that regularly hit the Ion size limit. The smallest of the aborting functions is 6K lines long and has 1.7K local variables. Given that both Chrome and Firefox slow down on the version with inlining, we're not alone in having difficulty with this.

On the modern web, this code would be compiled to target wasm, not JS.

I think we can go ahead and close this.