createSignal vs createStore for Deeply Nested State Management

Managing complex, nested data structures in SolidJS involves a trade-off between the granular subscription model of createSignal and the proxy-based architecture of createStore.

While createSignal offers direct reactivity, updating a deeply nested property requires cloning the entire object tree via spreading to trigger updates. Conversely, createStore allows for targeted path-based updates, which minimizes boilerplate and prevents the replacement of the entire state tree.

The uncertainty lies in the performance overhead of Proxy-based tracking when scaling to extremely large lists or highly frequent updates compared to the direct subscription model of Signals.

• Does the Proxy overhead in createStore significantly impact memory or CPU usage in high-frequency update scenarios compared to createSignal?
• At what scale of nested data does the boilerplate of Signal cloning outweigh the performance benefits of direct subscriptions?