feat(mobx): make 2022.3 @computed decorator lazy

[ashishkr96]

Summary

Fixes #4616.

The 2022.3 @computed getter decorator currently creates a ComputedValue eagerly via addInitializer for every decorated getter on every instance — even getters that are never read. On classes with several @computed getters across many instances this is wasted allocation and construction work.

This change defers ComputedValue creation to the first read of the decorated getter:

• decorate_20223_ in computedannotation.ts now stores a small factory closure on the admin's new lazyComputedKeys_ map instead of constructing the ComputedValue upfront.
• ObservableObjectAdministration.materializeLazyComputed_(key) lazily instantiates the ComputedValue and inserts it into values_ on demand. It is called from getObservablePropValue_ / setObservablePropValue_ (so the existing decorator getter wrapper Just Works) and from getAtom (so observe(o, key, ...) materialises before reading the underlying observable).
• isObservableProp checks lazyComputedKeys_ in addition to values_ so a decorated computed continues to report as observable before its first read.

The legacy makeObservable-based path (defineComputedProperty_) is unchanged.

Test plan

• yarn test (1036 passing, 14 skipped — full suite green)
• yarn test:types
• New regression tests in stage3-decorators.ts:
  • 4616 - @computed decorator should be lazy — asserts ComputedValue is not created until first read while isObservableProp still returns true, and an unused getter never runs.
  • 4616 - observe on @computed before first read materialises it — asserts observe(o, key) works for a lazy computed before any direct read.

[changeset-bot]

🦋 Changeset detected

Latest commit: dec5f98

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
mobx	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ashishkr96]

@kubk Can you please review this.

[mweststrate]

I can take a look on Monday as well, I cleared my schedule to do OSS maintenance that I didnt get go lately Op vr 1 mei 2026, 12:39 schreef Ashish kumar choubey < ***@***.***>:

…

*ashishkr96* left a comment (mobxjs/mobx#4639) <#4639 (comment)> @kubk <https://github.com/kubk> Can you please review this. — Reply to this email directly, view it on GitHub <#4639 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBASRLX6IMEWNSZLMPL4YR5F5AVCNFSM6AAAAACYLSLUTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNJYHEZDMNZXHE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mweststrate]

Hey @ashishkr96!

Thanks for this PR. The implementation looks semantically correct, so thanks for taking this effort! I left some comments on how I think this could be faster (since map lookups are relatively expensive)

The whole premise of this PR however is "On classes with several @computed getters across many instances this is wasted allocation and construction work.". Since closures are not free either (they capture several pieces of data in this PR), and there is now an extra map lookup on every hot path of reading an observable; do you have any measurement on the savings actually achieved by this PR? E.g. eithter in memory pressure or runtime speed? For example can you notice a difference when running yarn perf proxy in packages/mobx? (Or is there a benchmark missing there that would demonstrate the difference)

Thanks!

[mweststrate]

It looks like the return value is never uses, so change return type to void?

[mweststrate]

Or better, since this is on a super hot path, would it make sense to first lookup the entry in values_ and return it, and otherwise run the factory, and store, and return the factory result (to avoid another .get). This should reduce the amount of map lookups in the common scenario where initializer did already run (or is not a computed), from 2 to 1.

[ashishkr96]

done in a27ad5b. materializeLazyComputed_ now returns the freshly-built ComputedValue (or undefined when the key isn't lazy), and the callers do:

const observable = this.values_.get(key) ?? this.materializeLazyComputed_(key)

So the hot path (computed already materialised, plain observable, or non-lazy class) is one Map lookup. Same fix applied to setObservablePropValue_ and getAtom in type-utils.ts. Boolean return is gone too.

[ashishkr96]

Hey @mweststrate, thanks for the review!

Both points addressed in a27ad5b:

1. Hot-path collapse (your inline suggestion)

materializeLazyComputed_ now returns the freshly-built ComputedValue (or undefined when the key isn't lazy), and call sites do:

const observable = this.values_.get(key) ?? this.materializeLazyComputed_(key)

Hot path is back to one Map.get (computed already materialised, plain observable, or non-lazy class). Applied to getObservablePropValue_, setObservablePropValue_, and getAtom in type-utils.ts. The unused boolean return is gone.

2. Benchmarks

Existing yarn perf proxy doesn't exercise the @computed decorator path (it uses mobx.computed(fn, { context }) directly), so I wrote a small standalone benchmark on the side to validate the lazy premise — kept it out of the PR diff since it'd add a tsc step to the perf workflow; happy to upstream it under __tests__/perf/ if you'd like.

Shape: 50 000 instances of a class with 10 @computed getters where only one is read per instance (the realistic "wide class, sparse access" from #4616). Linux, Node 24, --expose-gc, 3 timed runs after one warmup:

state	construct heap	construct time	first-read time	re-read 5×
main (no lazy)	+304.9 MB	316–345 ms	52–54 ms	131–200 ms
PR original (lazy, 2 lookups)	+153.3 MB	233–270 ms	36–40 ms	140–149 ms
PR refactored (lazy, 1 lookup)	+153.3 MB	245–292 ms	36–41 ms	142–155 ms

So the lazy decorator's actual savings on the #4616 shape:

• −50 % heap during construction (305 → 153 MB on 50k×10 getters), since unread ComputedValues are never allocated.
• ~25 % faster construction for the same reason.
• The 1-lookup refactor matches the 2-lookup variant within run-to-run noise on this microbenchmark — the closure + extra Map probe weren't free, but with the refactor the steady-state read path is identical to main's.

I also ran yarn perf proxy 3× on the refactored branch — all 37 tests pass and the headline numbers (order system, array loop, computed memoization, etc.) are well within run-to-run jitter, which is expected since none of those tests touch the decorator path.

Happy to tweak the benchmark shape (different instances × getters × reads mix, or a runInAction path) — and let me know if you'd prefer the benchmark file checked in.

[mweststrate]

@ashishkr96 these benchmarks look great, better than I had intuitively expect! Yes please check in the benchmark. No additional benchmarks needed I think. Also mind marking the change as feat/minor?

After that I'll give it a final review, but thanks for wondering this.

Did you experiment with doing the same for ObservableValue as well? I suspect it'd wouldn't be as much of a delta since they have less administration, but intrigued now :)

[mweststrate]

note: the CI currently failed, but that should be fixed by doing a rebase.

[ashishkr96]

Did you experiment with doing the same for ObservableValue as well?

@mweststrate Yes, bigger delta than I expected. Quick exploration on a separate branch (explore/lazy-observable-4616), same wide-class/sparse-access shape (50k instances × 10 fields, 1 read per instance, 5 re-reads, Linux Node 24, --expose-gc, 3 timed runs after warmup):

state	construct heap	construct time	first-read time	re-read 5×
eager (current main behaviour)	+223.9 MB	615.7 ms	23.9 ms	82.5 ms
lazy @observable accessor (experimental)	+40.0 MB	82.1 ms	24.7 ms	23.0 ms
delta	−82.1%	−86.7%	within noise	−72%

The experimental change is one line in observableannotation.ts — drop the eager initializeObservable(this, value) call from the init callback, since the get/set handlers already lazy-materialise on first access (the accessor's backing slot still holds the initial value, so desc.get.call(this) returns it correctly).

Caveats — 3 tests in stage3-decorators.ts fail with this minimal change, all the same seams the @computed PR already closed:

• getAtom / observe(o, key) before first read — needs a materializeLazyObservable_ call mirroring materializeLazyComputed_ in getAtom.
• isObservableProp — needs to consult a lazyObservableKeys_ set.
• values_.keys() enumeration in inheritance tests — same union with lazy keys.

So the savings are real and the gaps are the same patterns we're already shipping for @computed. Happy to open a follow-up PR (feat(mobx): make @observable accessor lazy) once #4639 lands — the wins look meaningfully bigger than the @computed change (which was −50% heap / −25% construct on the same shape) because the eager ObservableValue + Atom per field is heavier than I'd assumed.

Benchmark file used (__tests__/perf/lazy-observable-decorator.ts) lives on the explore branch; can include it in the follow-up PR.

[ashishkr96]

Quick correction on the previous comment — I had only run the sparse-access shape (1 of 10 fields read per instance), which is the best case for lazy. Re-ran with all 10 fields read per instance to find the floor:

scenario	construct heap	construct ms	first-read ms	re-read ms
SPARSE eager	223.9 MB	595	23	82
SPARSE lazy	40.0 MB	82	25	23
FULL eager	223.9 MB	551	84	367
FULL lazy	40.0 MB	70	289 (+244%)	378

Lazy doesn't eliminate the allocation work, it defers it from construct to first-read. On the FULL shape, first-read regresses 3.4× — the deferred allocations land there. Total work (construct + first-read) is still less for lazy on both shapes (~107 ms vs ~618 sparse, ~360 ms vs ~635 full), likely from GC/JIT effects, but the steady-state win shrinks a lot once everything has been read.

Also worth flagging: the experimental change I measured is just the one-line deletion in init; the production version would still need the getAtom/isObservableProp/values_.keys() fixups that @computed got, plus a per-read branch I haven't measured.

Net read: lazy @observable is real but the headline number (−82% heap) is a sparse-access best case, not a steady-state win. Construction-time savings are robust, runtime savings depend on access pattern. Worth a follow-up PR, but framed as "construction-time perf" rather than "general perf win."