2nd/10_Wiki/Topics/Programming & Language/할당 타임라인(Allocation Timeline).md

---
id: wiki-2026-0508-할당-타임라인-allocation-timeline
title: 할당 타임라인 (Allocation Timeline)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Allocation Timeline, Memory Allocation Profiling, Heap Timeline]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [profiling, memory, devtools, performance, gc]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: javascript
  framework: chrome-devtools
---

# 할당 타임라인 (Allocation Timeline)

## 매 한 줄
> **"매 heap 의 시간 축 의 graph"**. Allocation Timeline 은 Chrome DevTools (Memory panel) 의 sampling profiler tool 로, recording 동안 매 N ms 마다 JS heap 의 allocation 을 sample 하여 어떤 코드 line 이 어떤 timestamp 에 얼마만큼 의 memory 의 allocate 했는지 visualize. 매 memory leak 의 hunt, 매 high-frequency allocation hotspot 의 identification 의 매 first-line tool.

## 매 핵심

### 매 DevTools Memory panel 의 3 modes
1. **Heap snapshot**: 매 single point-in-time 의 full snapshot. 매 leak diagnosis (3-snapshot technique).
2. **Allocation instrumentation on timeline** (allocations on timeline): 매 stack trace 와 함께 매 allocation 의 capture. 매 expensive 한 most-detailed.
3. **Allocation sampling**: 매 lightweight, statistical. 매 production-like profile.

### 매 timeline 의 read 법
- X 축: time.
- Y 축: bar 의 height = allocation size.
- **Blue bar**: 매 still-alive allocation 의 record 종료 시점.
- **Gray bar**: 매 collected allocation. 매 GC 의 reclaimed.
- 매 blue 가 많이 남으면 → potential leak source.

### 매 응용
1. SPA 의 leak detection — page navigate 후 reachable obj 의 monitor.
2. React re-render allocation 의 hotspot 식별.
3. Worker / animation loop 의 per-frame allocation 의 minimize.
4. Stream parser 의 backpressure 검증.

## 💻 패턴

### Chrome DevTools — Allocation 기록
```text
1. Open DevTools → Memory tab.
2. Select "Allocation instrumentation on timeline".
3. Click ●(record), perform workflow, click ⏹.
4. Filter by Constructor / Size.
5. Expand stack trace — file:line 의 click → Sources panel.
```

### 3-snapshot leak diagnosis
```text
1. Snapshot 1 (baseline)
2. Trigger workflow N times (open modal, close, ...).
3. Force GC (trash icon).
4. Snapshot 2.
5. Repeat workflow N times again, force GC.
6. Snapshot 3.
7. Filter "Comparison" — objects allocated between Snap1 and Snap2 still alive at Snap3.
   → That's the leak.
```

### Programmatic — performance.measureUserAgentSpecificMemory()
```javascript
if ('measureUserAgentSpecificMemory' in performance) {
  const result = await performance.measureUserAgentSpecificMemory()
  console.log(result.bytes)  // total bytes
  console.log(result.breakdown)  // per realm/type
}
```

### Node.js — heap profiling (built-in inspector)
```javascript
// node --inspect server.js
// Then in chrome://inspect → DevTools → Memory tab

// or programmatic
import { Session } from 'inspector'
const session = new Session()
session.connect()
session.post('HeapProfiler.startSampling')
// ... workload
session.post('HeapProfiler.stopSampling', (err, { profile }) => {
  fs.writeFileSync('heap.heapprofile', JSON.stringify(profile))
})
```

### Detect React leak (common pattern)
```jsx
// LEAK — interval 의 closure 의 stale state 의 retain
useEffect(() => {
  const id = setInterval(() => setCount(c => c + 1), 1000)
  // missing cleanup
}, [])

// FIX
useEffect(() => {
  const id = setInterval(() => setCount(c => c + 1), 1000)
  return () => clearInterval(id)
}, [])
```

### High-frequency allocation reduction
```javascript
// BAD — every frame allocates
function tick() {
  const v = { x: Math.random(), y: Math.random() }  // allocation per frame
  draw(v)
  requestAnimationFrame(tick)
}

// GOOD — reuse buffer
const v = { x: 0, y: 0 }
function tick() {
  v.x = Math.random()
  v.y = Math.random()
  draw(v)
  requestAnimationFrame(tick)
}
```

### WeakMap/WeakRef — GC-friendly cache
```javascript
const cache = new WeakMap()  // GC 의 reclaim 가능
function compute(obj) {
  if (cache.has(obj)) return cache.get(obj)
  const r = expensive(obj)
  cache.set(obj, r)
  return r
}
```

### FinalizationRegistry — leak detect in test
```javascript
const fr = new FinalizationRegistry(name => console.log(`${name} GC'd`))

function track(obj, name) {
  fr.register(obj, name)
}

// in test: track(component, 'Modal'); unmount; await gc(); 
// expect Modal GC'd to log
```

## 매 결정 기준
| 상황 | Tool |
|---|---|
| Live SPA 의 leak suspect | DevTools Memory → Allocation timeline + 3 snapshots |
| Production-like overhead 필요 | Allocation sampling |
| Detached DOM hunt | Heap snapshot → "Detached" filter |
| Total memory size monitoring | `performance.measureUserAgentSpecificMemory()` |
| Node server | `--inspect` + Chrome DevTools, 또는 clinic.js |
| Animation hotspot | Allocation timeline (short window) |

**기본값**: Allocation instrumentation on timeline 의 short (10-30s) recording. 매 3-snapshot 의 leak suspect 시.

## 🔗 Graph
- 부모: [[Performance_Profiling_and_Memory|Performance Profiling]] · [[Memory Management]]
- 변형: [[Nodejs_and_Backend_Optimization|Heap Snapshot]]
- 응용: [[Memory Leak Detection]]
- Adjacent: [[Chrome DevTools 메모리 프로파일링|Chrome DevTools]] · [[V8 Engine]]

## 🤖 LLM 활용
**언제**: User 가 "page slow over time" / "memory grows" / "browser crashes after 1h" 의 report 시. 매 Allocation timeline 의 first action.
**언제 X**: One-shot CPU bottleneck — 매 Performance panel (CPU profile) 의 prefer.

## ❌ 안티패턴
- **Snapshot 1개 만 보기**: leak 의 X-prove. 매 minimum 2-3 snapshots 의 compare.
- **GC 의 X-force**: snapshot 전 GC button 의 click 의 X-하면 매 noise 의 inflated.
- **Production minified code**: source map 의 X-load → stack trace 의 unreadable.
- **Long recording**: 100 MB+ 의 allocation timeline 의 DevTools 의 freeze.
- **Closures 의 ignore**: 매 detached DOM retainer 의 most-common 한 closure.

## 🧪 검증 / 중복
- Verified (Chrome DevTools docs 2026, V8 blog).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — DevTools allocation timeline, 3-snapshot leak hunt, Node profiling |