Web Worker에서 SharedArrayBuffer는 정말 성능을 개선할까?
분야
프로그래밍/소프트웨어 개발
대상자
Web Worker를 활용한 멀티스레드 처리, 오디오/비디오 처리, WebAssembly 통신을 담당하는 개발자
난이도: 중급~고급 (성능 최적화 및 메모리 관리 이해 필요)
핵심 요약
- *SharedArrayBuffer는 Web Worker 간 메모리 복사 없이 공유 가능** 하지만 성능 개선은 제한적
- Transfer Time 최적화 가능 (메모리 복사 생략)
- Processing Time 증가로 Total Time 개선 효과 제한적
- 보안 정책 필수 (Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp)
- 적합한 시나리오: 실시간 오디오 스트리밍, WebAssembly ↔ JS 데이터 전송
섹션별 세부 요약
- SharedArrayBuffer란?
- 저수준 메모리 객체로, Web Worker 간 참조 공유 가능
ArrayBuffer
와 유사하지만,TypedArray
로 접근 시 복사 대신 참조- 보안상 기본 비활성화 (특정 HTTP 헤더 필요)
- 대표 사용 사례: 오디오 처리, WebAssembly 통신
- 실험 목적 및 설계
- 성능 비교 기준: Transfer Time, Processing Time, Total Time
- 테스트 조건:
- 오디오 길이 및 반복 횟수 동적 조절
- performance.now()
로 시간 측정
- Float32Array
로 SharedArrayBuffer 접근
- 결과 분석: Transfer Time 개선 vs Processing Time 증가
- 실험 결과 및 해석
- Transfer Time: SharedArrayBuffer 사용 시 약 20ms 단축
- Processing Time: 래퍼 객체 생성 및 내부 락/메모리 배리어로 약 20ms 추가
- Total Time: 대부분 개선 효과 없음 또는 역전 (오디오 길이 증가 시 차이 확대)
- 성능 향상 조건:
- 작은 데이터량의 빈번한 전송 (예: 실시간 오디오 스트리밍)
- 복사 비용 높은 환경 (예: PCM 처리)
- 다중 워커 병렬 처리 요구 시
- 보안 및 사용 제한
- 보안 정책 필수:
```http
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
```
- 브라우저 제약: 사용 가능한 Worker 수 제한 (병렬 처리 효율성 감소 가능성)
- 트레이드오프: 병렬 처리 오버헤드 vs 단일 스레드 처리 효율성 비교 필요
결론
SharedArrayBuffer는 Transfer Time 최적화에 유리하지만, Processing Time 증가로 전체 성능 개선은 제한적.
- 실무 권장 사항:
- 실시간 데이터 전송 시 사용 (예: 오디오 스트리밍)
- 메모리 복사 비용 높은 환경에서 적용
- 브라우저 지원 확인 (Worker 수 제한 고려)
- 요약: "메모리 복사 없이 데이터 공유"라는 개념은 중요하지만, 구체적인 성능 향상은 시나리오에 따라 다름. 성능 최적화 시 Transfer Time 측면에 집중할 것.