Performance Settings (Beta)

Since Version 1.60.11 several Remember components expose experimental performance options under a Performance header in the Inspector. These features aim to cut down on redundant component lookups and registration overhead, but they are not a one‑click speed boost—use them only after understanding their impact and validating with profiling.

Components with Performance Settings

Component	Enable Performance Caching	Enable Batch Registration
RememberTransform	✅	✅
RememberGameObject	✅	✅
RememberRigidbody	✅	❌
RememberMeshRenderer	✅	❌
RememberSkinnedMeshRenderer	✅	❌

Note: Batch registration is currently supported only by RememberTransform and RememberGameObject. All others provide caching only.

Enable Performance Caching

When enabled, the component grabs references to frequently accessed Unity components (e.g., Rigidbody, MeshRenderer, CharacterController) during Awake and reuses them instead of calling GetComponent every time the object is saved or restored.

• Goal: Reduce the small but repeated cost of GetComponent calls, especially in large hierarchies.

• When to consider: Objects that persist throughout a session and are serialized/deserialized many times.

• Limitations:

  • Caches are not refreshed automatically if you add, remove, or swap the referenced component at runtime.

  • If a cached component is destroyed, subsequent operations may fail until the cache is rebuilt (e.g., on next scene load).

  • Savings are modest; caching won’t fix deeper performance bottlenecks.

Enable Batch Registration

Only available on RememberTransform and RememberGameObject, this option lets the SaveManager perform a single GetComponentsInChildren sweep to discover and register all Remember components in that object’s subtree. The work is spread over multiple frames via a coroutine, reducing recursion and per‑node GetComponent calls.

• Goal: Lower registration overhead for deep hierarchies that are instantiated or restored at runtime.

• When to consider: Prefabs with many Remember components created/destroyed frequently.

• Limitations & Caveats:

  • Registration order: Batched registration may not respect strict parent‑before‑child ordering. If your logic relies on deterministic order, leave this option disabled.

  • Scope: Only affects registration; it does nothing for runtime serialization/deserialization costs.

  • Partial support: Components that don’t implement batch registration fall back to the standard recursive approach.

  • Beta behavior: The API may change or be removed; unexpected edge cases (circular references, dynamic parenting, custom registration flows) are not guaranteed to work.

Best Practices & Warnings

1. Profile first: Measure actual bottlenecks before toggling these settings.

2. Selective use: Enable only on components where repeated calls are proven hot spots.

3. Edge cases: Complex hierarchies, runtime component replacement, or custom registration workflows may break when caching or batching is enabled.

4. Not a silver bullet: These features shave off overhead but won’t address heavy CPU/GPU work, large serialized payloads, or I/O constraints.

5. Beta disclaimer: Features are experimental and may produce unexpected behavior. Always validate in your project before shipping.

---

Enabling Performance Caching or Batch Registration can be beneficial in specific scenarios, but indiscriminate use may introduce bugs or offer negligible gains. Treat these toggles as fine‑tuning tools rather than blanket optimizations.