자바스크립트(JavaScript) 스트림 API, 성능 문제 해결할 새로운 대안 등장

게시물에서는 웹 스트림(Web Streams) API가 getReader()와 releaseLock()과 같은 과도한 API 오버헤드(API Overhead)를 가지고 있다고 지적한다. 특히, 락(Lock) 관리, BYOB(Bring Your Own Buffer)와 같은 기능들이 오히려 개발의 어려움을 가중시킨다고 비판한다. 비동기 반복자(Async Iterators)가 등장했음에도 불구하고, 웹 스트림(Web Streams)은 기존의 복잡한 방식을 유지하여 개발자들이 겪는 어려움을 해결하지 못했다는 점을 강조한다. 이러한 설계는 성능 저하의 원인이 되기도 한다.

BYOB(Bring Your Own Buffer)는 스트림에서 메모리 버퍼를 재사용하여 성능을 최적화하려는 시도였지만, 실제 사용에서는 복잡성만 증가시켰다는 비판을 받는다. 게시물에 따르면, BYOB는 별도의 리더(Reader) 타입과 버퍼 관리, 그리고 ArrayBuffer의 detached semantics를 이해해야 하는 등, 개발자에게 과도한 부담을 준다. 또한, BYOB는 async iteration이나 TransformStreams와 호환되지 않아, 데이터 격리 아키텍처(Data Isolation Architecture)를 구현하는 데 제약이 따른다.

백프레셔(Backpressure)는 느린 소비자(Consumer)가 빠른 생산자(Producer)에게 속도를 늦추도록 신호를 보내는 메커니즘이지만, 웹 스트림(Web Streams)에서는 제대로 작동하지 않는다는 지적이 나온다. 게시물에서는 controller.enqueue()가 desiredSize가 음수일 때도 성공하는 점을 문제로 지적하며, tee()와 같은 기능이 백프레셔(Backpressure)를 무시하고 무제한적인 메모리 증가(Unbounded Memory Growth)를 유발할 수 있다고 비판한다. 이러한 문제로 인해, 백프레셔(Backpressure)는 성능 보장(Performance Guarantee)에 기여하지 못한다.

게시물에서 제안하는 새로운 API는 async iterator를 기반으로 하여, 스트림을 async iterable로 간주한다. 이로 인해 getReader()와 같은 복잡한 API 없이 for await...of 구문을 사용하여 간결하게 스트림을 처리할 수 있다. 또한, pull-through transforms, 명시적인 백프레셔(Backpressure) 정책, 그리고 동기/비동기 분리 등, 다양한 설계 원칙을 통해 성능을 개선하고자 한다. 벤치마크 결과에 따르면, 새로운 API는 웹 스트림(Web Streams)보다 최대 120배 빠른 성능을 보였다고 한다.

웹 스트림(Web Streams)의 성능 문제를 해결하기 위해, Node.js, Deno, Bun, Cloudflare Workers 등 주요 런타임(Runtime)들은 자체적인 최적화를 시도해왔다. 하지만, 이러한 최적화는 스펙(Spec)의 제약으로 인해 어려움을 겪고 있으며, 런타임 간의 호환성 문제(Compatibility Issues)를 야기할 수 있다. Vercel의 연구에 따르면, Node.js의 웹 스트림(Web Streams) 구현에서 promise를 제거하는 것만으로도 상당한 성능 향상을 얻을 수 있다고 한다. 이러한 노력은 웹 스트림(Web Streams) API의 근본적인 문제점을 보여준다.