UNPKG

@snow-tzu/type-config

Version:

Core configuration management system with Spring Boot-like features

91 lines (65 loc) • 4.51 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
# Benchmark Results Generated: 2024-11-23T11:35:00.000Z Node.js: v24.5.0 Platform: darwin arm64 ## Configuration Loading Performance | Benchmark | Ops/Sec | Avg Time | Min | Max | p50 | p95 | p99 | Iterations | |--------------------------------------|-----------|----------|----------|---------|----------|----------|----------|------------| | **Load small config** | 8,851 | 0.113ms | 0.105ms | 1.986ms | 0.109ms | 0.127ms | 0.189ms | 8,852 | | **Load medium config (50 sections)** | 6,369 | 0.157ms | 0.150ms | 0.534ms | 0.154ms | 0.168ms | 0.217ms | 6,370 | | **Load large config (200 sections)** | 2,718 | 0.368ms | 0.357ms | 0.647ms | 0.364ms | 0.383ms | 0.425ms | 2,718 | | **Get value by path** | 3,664,201 | <0.001ms | <0.001ms | 2.692ms | <0.001ms | <0.001ms | <0.001ms | 3,664,205 | | **Get from container** | 6,372,527 | <0.001ms | <0.001ms | 4.290ms | <0.001ms | <0.001ms | <0.001ms | 6,372,533 | ### Key Findings - ✅ **Configuration loading scales linearly** with config size - ✅ **Direct value access is extremely fast** at >3.6M ops/sec - ✅ **Container access is fastest** at >6.3M ops/sec (use this for best performance) - ✅ **Sub-millisecond loading** for typical configurations (<100 sections) ## Memory Usage Run with: `yarn benchmark:memory` | Scenario | Heap Used | Heap Δ | RSS | RSS Δ | Notes | |---------------------------|-----------|-----------|----------|-----------|-------------------------| | **Baseline** | 4.23 MB | - | 34.12 MB | - | Node.js baseline | | **Small (10 sections)** | 5.45 MB | +1.22 MB | 36.78 MB | +2.66 MB | Minimal overhead | | **Medium (100 sections)** | 7.89 MB | +3.66 MB | 41.23 MB | +7.11 MB | Typical app size | | **Large (500 sections)** | 18.34 MB | +14.11 MB | 58.45 MB | +24.33 MB | Large enterprise config | | **10 instances** | 12.56 MB | +8.33 MB | 48.91 MB | +14.79 MB | ~0.8 MB per instance | ### Key Findings - ✅ **Low memory overhead**: ~1-2 MB for typical configs - ✅ **Linear scaling**: Memory grows linearly with config size - ✅ **Efficient multi-instance**: ~0.8 MB per additional instance - ✅ **Production-ready**: Suitable for memory-constrained environments ## Analysis ### Configuration Loading | Config Size | Ops/Sec | Time per Load | Relative Speed | |----------------------|---------|---------------|-----------------| | Small | 8,851 | 0.11ms | Baseline (1.0x) | | Medium (50 sections) | 6,369 | 0.16ms | 0.72x | | Large (200 sections) | 2,718 | 0.37ms | 0.31x | **Insight**: Loading time increases linearly with config size. For most applications, loading overhead is <0.5ms. ### Configuration Access Performance | Access Method | Ops/Sec | Relative Speed | Recommendation | |-----------------------|---------|--------------------|------------------| | **Container (typed)** | 6.3M | **Fastest** (1.0x) | ✅ Use this | | **Direct path** | 3.6M | 0.58x | ⚠️ Fallback only | **Insight**: Container-based access is 1.7x faster than path-based access. Always prefer typed configuration classes. ### Memory Footprint Analysis | Metric | Value | Assessment | |-----------------------------|--------------|---------------| | Per-instance overhead | ~1-2 MB | ✅ Excellent | | Memory scaling | Linear | ✅ Predictable | | Multi-instance efficiency | ~0.8 MB each | ✅ Very good | | Large config (500 sections) | +14 MB | ⚠️ Monitor | **Insight**: Memory usage is very efficient for typical configurations. Monitor large configs (>200 sections). ## Recommendations 1. **Use typed container access** for best performance (6.3M vs 3.6M ops/sec) 2. **Cache configuration instances** - loading overhead is ~0.1-0.4ms depending on size 3. **Keep configuration sizes reasonable** - 50-100 sections perform well 4. **Disable hot reload in production** to eliminate file watching overhead 5. **Monitor memory** with large configurations (>200 sections) ## System Information - **CPU**: Apple M1/M2 (ARM64) - **Memory**: 16GB - **OS**: macOS Sonoma - **Node.js**: v24.5.0 Results will vary based on hardware and system load.