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

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-할당-타임라인-allocation-timeline	할당 타임라인 (Allocation Timeline)	10_Wiki/Topics	verified	self	Allocation Timeline Memory Allocation Profiling Heap Timeline	none	A	0.9	applied	profiling memory devtools performance gc		2026-05-10	pending	language framework javascript 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 기록

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

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()

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)

// 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)

// 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

// 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

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

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 · Memory Management
• 변형: Nodejs_and_Backend_Optimization
• 응용: Memory Leak Detection
• Adjacent: Chrome DevTools Memory Profiling · 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