fix(signal): reduce duplicate observer registrations in repeated signal reads

[oanlit]

Summary

When a signal is read repeatedly within the same computation (e.g. inside loops),
the current implementation registers the same observer multiple times.

This leads to unnecessary growth of internal tracking structures, including:

• observers
• observerSlots
• sources
• sourceSlots

This issue is especially noticeable in patterns such as:

• Tight loops:

createEffect(() => {
  for (let i = 0; i < 1000; i++) a();
});

• Iteration over store arrays:

createEffect(() => {
  for (const item of arrayStore) {
    _ = item;
  }
});

In these cases, repeated signal reads (e.g. length, indexed access, or direct signal calls)
cause the same computation to be registered multiple times.

---

This PR introduces a lightweight deduplication mechanism by tracking the last registered observer per signal.

• Adds lastObserver to SignalState
• Only registers the current computation if it differs from lastObserver
• Resets lastObserver during cleanup

This significantly reduces redundant registrations in common scenarios while keeping the cost of deduplication O(1) and preserving existing behavior.

---

How did I test this change?

To enable verification of internal observer behavior in tests, this PR slightly adjusts the return value of createSignal:

const result = [readSignal.bind(s), setter] as Signal<T | undefined>;
if (IS_DEV) (result as any).state = s;
return result;

2. Added a test case that repeatedly reads a signal inside a loop:

const a = createSignal(0);
const dispose = createRoot(dispose => {
  createEffect(() => {
    for (let i = 0; i < 1000; i++) {
      a[0]();
    }
  });
  return dispose;
});
expect((a as any).state.observers.length).toBe(1);
expect((a as any).state.observerSlots.length).toBe(1);
expect((a as any).state.observers[0].sources.length).toBe(1);
expect((a as any).state.observers[0].sourceSlots.length).toBe(1);
dispose();

Before this change:

• observers.length === 1000

After this change:

• observers.length === 1

2. Verified similar behavior with store array iteration:

const [arrayStore] = createStore([1, 2, 3, 4, 5]);

createEffect(() => {
  for (const item of arrayStore) {
    _ = item;
  }
});

Confirmed that repeated reads (e.g. length and indexed access) no longer
cause excessive observer registrations.

3. Ran full test suite:

pnpm build
pnpm test

All tests pass.

4. Manually inspected that:

• observerSlots and sourceSlots no longer grow excessively
• No regression in reactivity behavior

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0bb4dad

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[ryansolid]

Thanks for digging into this. The repeated registration issue is real, but I wanted to avoid adding extra signal state or exposing internal SignalState through the createSignal return tuple for testing.

I landed a smaller version in fae8fbe that uses the existing observer slot structure instead: when the current listener is already the last observer for a source, readSignal skips adding another source/observer pair. This keeps the common repeated-read case from growing the tracking arrays while avoiding new cleanup state.

I also added behavior coverage for repeated reads, disposal cleanup, and conditional dependency cleanup/re-subscription. Thanks again for identifying the issue and providing the repro direction.