Rust 비동기(Async)의 성능 개선을 위한 컴파일러 최적화, 어디까지 왔나?

본문에서는 비동기 Rust(Async Rust)가 바이너리 크기 증가 및 성능 저하를 유발하는 주요 원인으로 지목된다. 특히, 각 `async` 블록(Block)마다 생성되는 상태 머신(State Machine)과 불필요한 코드 중복이 문제로 제기된다. 저자는 컴파일러 최적화를 통해 이러한 문제를 해결하고, 임베디드 시스템(Embedded System)과 같이 제한된 환경에서의 성능 개선을 목표로 한다. 컴파일러 최적화(Compiler Optimization)를 통해 바이너리 크기를 줄이고, 런타임(Runtime) 성능을 향상시킬 수 있다는 점을 강조한다.

저자는 MIR(Mid-level Intermediate Representation) 단계에서의 최적화를 통해 성능을 개선할 수 있다고 주장한다. 특히, `Future::poll` 함수가 `Ready` 상태에서 다시 호출될 때 `panic`을 발생시키는 대신 `Pending`을 반환하도록 변경하여 바이너리 크기를 2~5% 감소시키는 실험 결과를 제시한다. 또한, 불필요한 상태 머신(State Machine)을 제거하기 위해, `async` 블록 내에 `await`가 없는 경우 상태 머신을 생성하지 않도록 하는 방안을 제안한다. MIR 최적화(MIR Optimization)를 통해 코드 중복을 줄이고, 런타임(Runtime) 오버헤드를 감소시킬 수 있다.

본문에서는 인라인(Inlining) 최적화의 중요성을 강조하며, 현재 Rust 컴파일러가 생성된 `Future`를 인라인하지 못하는 문제를 지적한다. 특히, `async fn foo().await`와 같은 패턴에서 `foo` 함수의 상태 머신(State Machine)이 `bar` 함수 내부에 인라인되지 않아 성능 저하가 발생한다고 설명한다. 저자는 인라인(Inlining)을 통해 코드 중복을 줄이고, 추가적인 최적화 기회를 확보할 수 있다고 주장한다. 하지만, 현재 Rust 컴파일러의 구조적 한계로 인해 인라인 최적화가 제대로 이루어지지 않는다는 점을 지적한다.

커뮤니티에서는 비동기 Rust(Async Rust)의 복잡성 및 생태계 의존성에 대한 우려와 함께, 컴파일러 최적화의 필요성에 공감하는 분위기다. 특히, Tokio와 같은 특정 런타임(Runtime)에 대한 과도한 의존성을 지적하며, 보다 유연하고 효율적인 비동기 프로그래밍 환경을 요구한다. 또한, 코드 중복(Code Duplication)을 줄이고, 개발 생산성을 향상시키기 위한 다양한 개선 방안이 제시된다. 데이터 미저장 정책(Zero-Retention Policy)을 통해 보안성을 강화하고, 개발자 경험을 개선해야 한다는 의견도 제시된다.