Anchor Performance - Blazingly Fast State Management for Web Applications
Anchor is designed from the ground up to deliver a blazingly fast and fluid user experience. Our performance philosophy is rooted in a single principle: doing the absolute minimum amount of work necessary to keep the UI in perfect sync with your application state.
FAQ
Why there such huge performance gaps between Classic Todo List and Anchor Todo List?
- Wasted Re-renders - Classic Todo App re-renders every time a todo item is added, changed, or removed.
- Heavy Computation - Classic Todo App makes a copy of the entire state tree every time a todo item is added, changed, or removed. As the app grows, the time taken to compute this will increase linearly (O(N)).
Fine-Grained Reactivity
This is the cornerstone of Anchor's performance. Traditional reactive frameworks often re-render large components or entire subtrees of the UI whenever any piece of state changes. This is inefficient and leads to a phenomenon known as "wasted renders".
Anchor takes a different approach. It tracks dependencies at the most granular level possible, ensuring that when you update a specific piece of state, only the exact components that are subscribed to that data will re-render.
How it works:
- Subscribe to Data: When a component needs to display a piece of state, it automatically subscribes to it.
- Change Detection: When that state changes, Anchor detects the mutation.
- Targeted Update: Instead of re-rendering a large, parent component, Anchor only triggers an update on the one component that needs to reflect the new data.
This approach means that your application remains fast and responsive, regardless of how complex your state tree becomes.
Optimized State Updates
Anchor's "direct mutation" within a write contract is not just a developer convenience; it's a significant performance optimization.
- The Problem with Deep Clones: In an immutable model that relies on deep cloning, every state update requires copying potentially massive objects. For large state trees, this is a computationally expensive operation that can cause noticeable lag.
- Anchor's Solution: By using a proxy-based system, Anchor allows you to use a simple, direct mutation syntax (
state.user.name = 'new name') without actually mutating the original, immutable state. This avoids the need for expensive deep clones and provides the best of both worlds: intuitive code and superior performance.
Minimal Overhead
The Anchor library itself is small and lightweight. Our goal is to provide a comprehensive solution without a bloated runtime. This means:
- Fast Startup Time: Your application loads and becomes interactive faster because there is less JavaScript to parse and execute.
- Efficient Memory Usage: Anchor's core is designed for efficiency, consuming minimal memory and leaving more resources for your application's logic.
By combining fine-grained reactivity with optimized state updates and a minimal footprint, Anchor empowers you to build applications that feel instant and responsive to every user interaction.
Benchmark Results
This benchmark report provides hard data and visual proof of Anchor's superior performance, demonstrating its ability to handle scale and complexity without the performance bottlenecks of traditional state management.
Test Scenarios
The following metrics were captured from a live demo comparing an application built with a traditional reactive model against the same application built with Anchor.
- Item Addition: Rapidly adding 1000 new todo items to a list.
- Item Toggling: Rapidly toggling a single item 25 times within a list of over 1000 items.
Each operation is debounced by 5ms.
Performance Metrics
| Metric | Classic | Anchor | Ratio |
|---|---|---|---|
| Adding 1000 Items | |||
| Start FPS | 199 fps | 198 fps | Raw fps |
| Start Render Time | 1.7 ms | 1 ms | ~1.70x |
| Degraded/Later FPS | 14.4 fps | 100.8 fps | ~7.00x |
| Late Render Time | 111.6 ms | 1.2 ms | ~93.00x |
| Time To Finish | 82,603 ms (82.6s) | 15,185 ms (15.1s) | ~5.44x |
| Toggling an item 25 times (103 items) | |||
| FPS | 16.8 fps | 182.4 fps | ~10.86x |
| Render Time (Average) | 119 ms | 0.4 ms | ~297.50x |
| Render Time (Peak) | 380 ms | 1 ms | ~380.00x |
| Time To Finish | 5,477 ms (5.4s) | 384 ms | ~14.26x |
Analysis & Key Takeaways
The data from these tests is conclusive: Anchor fundamentally redefines what's possible in web application performance.
- Efficiency at Scale: The Classic App's performance degrades dramatically as the list grows. Its render time for a single item update explodes to 111 ms, and its frame rate plummets to a choppy 16 fps. In contrast, Anchor's render time remains stable at a blazingly fast 1ms, with a fluid 108 fps.
- Classic immutability bottleneck: The Classic App's performance is also impacted by the immutability approach. Each item addition need to clone the entire list, leading the time and resource consumption is increased as the list size increases.
- The Problem of Wasted Renders: The Classic App re-renders components that don't need to change, leading to a massive render count of 503,503 (O(N)). Anchor, with its fine-grained reactivity, only renders what's necessary, resulting in count of just 1,003 (O(1), the same with the items count).
- A Superior User Experience: The tangible impact is clear. The Anchor app is ~297x faster at completing the toggling action and ~93x faster at adding items. This translates to an application that feels instant, responsive, and a joy to use.
These metrics prove that Anchor's architectural philosophy is a solution to the scalability problems facing modern web applications.