feat(query-engine-wasm): exclude native-drivers only errors from wasm32 target

[jkomyno]

This PR is a follow-up of #4615.
This PR closes https://github.com/prisma/team-orm/issues/763.
This PR contributes to https://github.com/prisma/team-orm/issues/584.

The current reduction of the gzip'd bundle size is around ~9 KB.

---

[github-actions]

WASM Size

Engine	This PR	Base branch	Diff
WASM	2.719MiB	2.746MiB	-28.396KiB
WASM (gzip)	1.002MiB	1.011MiB	-9.348KiB

[codspeed-hq]

CodSpeed Performance Report

Merging #4616 will not alter performance

_{Comparing feat/exclude-native-errors-from-wasm32 (5ad7d0b) with main (0fb4ba0)}

Summary

✅ 11 untouched benchmarks

[github-actions]

✅ WASM query-engine: no benchmarks have regressed

Full benchmark report

DATABASE_URL="postgresql://postgres:postgres@localhost:5432/bench?schema=imdb_bench&sslmode=disable" \
node --experimental-wasm-modules query-engine/driver-adapters/executor/dist/bench.mjs
cpu: AMD EPYC 7763 64-Core Processor
runtime: node v18.19.0 (x64-linux)

benchmark                   time (avg)             (min … max)       p75       p99      p995
-------------------------------------------------------------- -----------------------------
• movies.findMany() (all - 25000)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline  308.04 ms/iter (305.21 ms … 316.43 ms) 308.11 ms 316.43 ms 316.43 ms
Web Assembly: Latest    315.74 ms/iter (311.88 ms … 320.77 ms) 317.05 ms 320.77 ms 320.77 ms
Web Assembly: Current   313.74 ms/iter (309.89 ms … 318.74 ms) 314.47 ms 318.74 ms 318.74 ms
Node API: Current       229.84 ms/iter (220.53 ms … 240.21 ms) 233.51 ms 240.21 ms 240.21 ms

summary for movies.findMany() (all - 25000)
  Web Assembly: Current
   1.37x slower than Node API: Current
   1.02x slower than Web Assembly: Baseline
   1.01x faster than Web Assembly: Latest

• movies.findMany({ take: 2000 })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   12.34 ms/iter   (11.92 ms … 15.17 ms)  12.42 ms  15.17 ms  15.17 ms
Web Assembly: Latest     12.95 ms/iter   (12.09 ms … 21.79 ms)  12.58 ms  21.79 ms  21.79 ms
Web Assembly: Current    12.82 ms/iter    (12.34 ms … 18.2 ms)  12.54 ms   18.2 ms   18.2 ms
Node API: Current         9.44 ms/iter    (8.99 ms … 12.99 ms)   9.52 ms  12.99 ms  12.99 ms

summary for movies.findMany({ take: 2000 })
  Web Assembly: Current
   1.36x slower than Node API: Current
   1.04x slower than Web Assembly: Baseline
   1.01x faster than Web Assembly: Latest

• movies.findMany({ where: {...}, take: 2000 })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline    2.04 ms/iter     (1.86 ms … 3.43 ms)   2.04 ms   3.38 ms    3.4 ms
Web Assembly: Latest      2.09 ms/iter     (1.89 ms … 3.58 ms)   2.04 ms    3.4 ms   3.44 ms
Web Assembly: Current      2.1 ms/iter     (1.89 ms … 3.45 ms)   2.05 ms   3.41 ms   3.43 ms
Node API: Current         1.57 ms/iter      (1.46 ms … 2.1 ms)   1.59 ms   1.81 ms   2.08 ms

summary for movies.findMany({ where: {...}, take: 2000 })
  Web Assembly: Current
   1.34x slower than Node API: Current
   1.03x slower than Web Assembly: Baseline
   1.01x slower than Web Assembly: Latest

• movies.findMany({ include: { cast: true } take: 2000 }) (m2m)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   12.22 ms/iter    (11.9 ms … 13.65 ms)  12.28 ms  13.65 ms  13.65 ms
Web Assembly: Latest     12.44 ms/iter   (12.07 ms … 15.11 ms)  12.48 ms  15.11 ms  15.11 ms
Web Assembly: Current    12.47 ms/iter   (12.36 ms … 12.81 ms)   12.5 ms  12.81 ms  12.81 ms
Node API: Current         9.41 ms/iter       (8.92 ms … 10 ms)   9.55 ms     10 ms     10 ms

summary for movies.findMany({ include: { cast: true } take: 2000 }) (m2m)
  Web Assembly: Current
   1.32x slower than Node API: Current
   1.02x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movies.findMany({ where: {...}, include: { cast: true } take: 2000 }) (m2m)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline    1.96 ms/iter     (1.85 ms … 3.23 ms)   1.94 ms   2.93 ms   3.18 ms
Web Assembly: Latest      1.98 ms/iter     (1.88 ms … 4.41 ms)   1.96 ms   2.79 ms   2.84 ms
Web Assembly: Current     1.95 ms/iter     (1.87 ms … 3.18 ms)   1.94 ms   2.88 ms   3.12 ms
Node API: Current         1.56 ms/iter     (1.48 ms … 2.19 ms)   1.57 ms   1.83 ms   1.92 ms

summary for movies.findMany({ where: {...}, include: { cast: true } take: 2000 }) (m2m)
  Web Assembly: Current
   1.25x slower than Node API: Current
   1x faster than Web Assembly: Baseline
   1.01x faster than Web Assembly: Latest

• movies.findMany({ take: 2000, include: { cast: { include: { person: true } } } })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline    12.4 ms/iter    (11.9 ms … 17.71 ms)   12.4 ms  17.71 ms  17.71 ms
Web Assembly: Latest     12.44 ms/iter   (12.26 ms … 14.54 ms)  12.44 ms  14.54 ms  14.54 ms
Web Assembly: Current    12.54 ms/iter   (12.13 ms … 16.83 ms)  12.55 ms  16.83 ms  16.83 ms
Node API: Current         9.46 ms/iter     (9.21 ms … 10.8 ms)   9.59 ms   10.8 ms   10.8 ms

summary for movies.findMany({ take: 2000, include: { cast: { include: { person: true } } } })
  Web Assembly: Current
   1.33x slower than Node API: Current
   1.01x slower than Web Assembly: Baseline
   1.01x slower than Web Assembly: Latest

• movie.findMany({ where: { ... }, take: 2000, include: { cast: { include: { person: true } } } })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline    1.91 ms/iter     (1.83 ms … 2.96 ms)    1.9 ms   2.48 ms   2.84 ms
Web Assembly: Latest      1.93 ms/iter     (1.84 ms … 2.77 ms)   1.93 ms   2.52 ms   2.67 ms
Web Assembly: Current     1.94 ms/iter     (1.86 ms … 2.84 ms)   1.93 ms   2.51 ms    2.8 ms
Node API: Current         1.59 ms/iter     (1.51 ms … 2.01 ms)    1.6 ms   1.82 ms   1.99 ms

summary for movie.findMany({ where: { ... }, take: 2000, include: { cast: { include: { person: true } } } })
  Web Assembly: Current
   1.22x slower than Node API: Current
   1.02x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movie.findMany({ where: { reviews: { author: { ... } }, take: 100 }) (to-many -> to-one)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline  959.45 µs/iter    (867.5 µs … 1.62 ms) 942.12 µs   1.59 ms   1.61 ms
Web Assembly: Latest    936.92 µs/iter   (862.36 µs … 1.85 ms) 924.02 µs   1.55 ms   1.58 ms
Web Assembly: Current   943.13 µs/iter   (870.48 µs … 1.59 ms) 932.83 µs   1.51 ms   1.55 ms
Node API: Current       858.57 µs/iter    (814.82 µs … 1.1 ms) 872.38 µs   1.02 ms   1.05 ms

summary for movie.findMany({ where: { reviews: { author: { ... } }, take: 100 }) (to-many -> to-one)
  Web Assembly: Current
   1.1x slower than Node API: Current
   1.01x slower than Web Assembly: Latest
   1.02x faster than Web Assembly: Baseline

• movie.findMany({ where: { cast: { person: { ... } }, take: 100 }) (m2m -> to-one)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline  914.69 µs/iter   (863.38 µs … 1.52 ms) 914.89 µs   1.28 ms   1.44 ms
Web Assembly: Latest     927.1 µs/iter   (876.38 µs … 1.48 ms) 927.92 µs   1.29 ms    1.4 ms
Web Assembly: Current   932.96 µs/iter   (885.87 µs … 1.42 ms) 934.48 µs   1.27 ms   1.28 ms
Node API: Current       847.05 µs/iter   (760.57 µs … 1.14 ms) 867.11 µs   1.09 ms   1.11 ms

summary for movie.findMany({ where: { cast: { person: { ... } }, take: 100 }) (m2m -> to-one)
  Web Assembly: Current
   1.1x slower than Node API: Current
   1.02x slower than Web Assembly: Baseline
   1.01x slower than Web Assembly: Latest

After changes in 5ad7d0b

[jkomyno]

There are a bunch of clippy issues, such as:

warning: large size difference between variants
  --> quaint/src/connector/connection_info.rs:25:1
   |
25 | / pub enum ConnectionInfo {
26 | |     #[cfg(not(target_arch = "wasm32"))]
27 | |     Native(NativeConnectionInfo),
   | |     ---------------------------- the largest variant contains at least 384 bytes
28 | |     External(ExternalConnectionInfo),
   | |     -------------------------------- the second-largest variant contains at least 32 bytes
29 | | }
   | |_^ the entire enum is at least 384 bytes
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
   = note: `#[warn(clippy::large_enum_variant)]` on by default
help: consider boxing the large fields to reduce the total size of the enum
   |
27 |     Native(Box<NativeConnectionInfo>),
   |            ~~~~~~~~~~~~~~~~~~~~~~~~~

[jkomyno]

warning: large size difference between variants

Background info: if we introduced a Box layer in ConnectionInfo::Native, none of these pattern-matching strattegies would be feasible in stable Rust.

Having a large ConnectionInfo::Native variant branch is unfortunate, as the sole reason Native exists is to provide a well-enclosed expression block to which we can apply the #[cfg(not(target_arch = "wasm32"))] conditional compilation flag, both in the enum declaration and when pattern matching on it. This would of course not affect memory allocation in Wasm, but it could degrade memory allocations and optimisations for query-engine-node-api and the binary query-engine.

[jkomyno]

Thank you for your reply.

Not sure if I understand the above correctly. Are you saying that a big enum variant size is affecting the query-engine size at all?

No, I’m saying it would impact memory allocation in query-engine-node-api and the binary query-engine . It would have 0 effects on Wasm, as when targeting wasm32 we’d have an enum with a single variant

[miguelff]

No, I’m saying it would impact memory allocation in query-engine-node-api and the binary query-engine . It would have 0 effects on Wasm, as when targeting wasm32 we’d have an enum with a single variant

Then I think it will be negligible, given it happens once per query. Go ahead and check benchmarks, if there's no regression, then we will know we are good.

[jkomyno]

Vitess 8 is failing, I'll look into it but it doesn't seem related to this PR: https://github.com/prisma/prisma-engines/actions/runs/7339908596/job/19985031968?pr=4616#step:12:2364

[jkomyno]

(There are a couple of hiccups to fix, as per CI. I'm on it)

[jkomyno]

SE: integration tests / vitess_8_0 keeps on failing, I haven't yet pinpointed what caused that problem.

Update: found the problem and solved it.