Optimizer wishlist

[wmertens]

segment generation

• make QRL dynamic import functions modules scoped and memoize, so that we don't make promises needlessly.
  For example,
  qrl(() => import('./foo.js'), 'foo', ...)
  would become
  /* top level */ const importFoo = () => import('./foo.js');
/* ...some function... */ qrl(importFoo, 'foo', ...)
  and qrl would use a WeakMap to keep track of resolved imports.
• If a QRL has no scope captures, move it to module scope entirely
• JSX attributes like {props.foo.thing ? props.foo.thing * 2 : null} should become
  fnSignal(p0 => p0.thing ? p.thing * 2 : null, props.foo)
  and not
  fnSignal(p0 => p0.foo.thing ? p.foo.thing * 2 : null, props).
  This helps with serializing only store data that's used.
  Exception for when an intermediate prop is value, then it is probably a signal and it should be passed as a signal.
  fnSignal(p0 => p0.value.thing ? p.value.thing * 2 : null, signal)
• in prod mode, if a segment has no imports other than qwik, rewrite it with p0, p1 etc and put it in / named after the hash of the segment code, and then re-export it. This will deduplicate the segment code.

  // original qrl123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export const qrl123 = () => { const [signal] = useLexicalScope(); signal.value++ }
  
  // /segment-hash123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export default ()=>{const [p0] = useLexicalScope();p0.value++;}
  
  // new qrl123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export {default as qrl123} from '/segment-hash123.js'

  this needs some care in plugin.ts, which currently expects segments to be in the same path as the parent.
• when a qrl references to itself, it should be rewritten with a helper object.
  This is legal JS but breaks during segmentation because of the scope capture:

  const store = useStore({ foo: 3, getFoo: $(() => store.foo) })
  // optimizer makes this, which breaks because of using store directly in the definition of store
  const store = useStore({
    foo: 3,
    getFoo: qrl(() => {
      const [p0] = useLexicalScope()
      return p0.t.foo;
    }, 'hash123', [store])
  })

  Instead, the optimizer should convert this to

  const _tmp = { }
  const store = _tmp.t = useStore({
    foo: 3,
    getFoo: qrl(() => {
      const [p0] = useLexicalScope()
      return p0.t.foo;
    }, 'hash123', [_tmp])
  })

• when encountering {...props}, make it so that var and const props are handled efficiently

Super optimization opportunities

• add annotations to captured scope to know if they are only read or also written to. This can be used to determine if a signal should be serialized with its effects; if nothing writes to the signal or its signal graph, then no effects can ever run.
  Meaning, during SSR when you're checking an event handler for state to serialize, you mark RO signals as such and skip their effects for now. Any RW signals have to add their effects, and when they encounter e.g. a computed signal, that also becomes RW.
  This way we avoid data and JS that will never be used.
• add annotations for used contexts to segments. When you SSR an event handler, check its entire dynamic import graph for used contexts, and add those to the state roots.
  This way we avoid missing contexts for dynamically added components.
  Note that this only works for statically used contexts. When using a dynamic context id, we fall back to the current behavior, which requires explicitly calling useContext after useContextProvider when you want to force context inclusion.

optimizer code

• make sure cargo bench works and set up https://github.com/benchmark-action/github-action-benchmark to track performance over time. Do this before oxc migration.
• migrate to oxc for increased speed and better docs
• The output format needs simplifying, we're not using a bunch of the fields
• Get rid of the fs related code, single file processing only
• add benchmarks as part of CI and complain when runtime or size increase
• move the binaries into individual packages and add them as optional deps with cpu-dependencies, like esbuild and sharp do. This will decrease the qwik bundle size by a lot
• use cross builds so we don't need separate runners in CI
• don't use any experimental rust features and switch to the stable toolchain