[cpython] asyncio 프로토콜 데이터 처리 최적화: O(N^2)에서 O(N)으로

2026년 7월 25일수정: 2026년 7월 25일

PR 링크: python/cpython#150622 상태: Merged | 변경: +34 / -5

들어가며

Python의 asyncio 라이브러리는 비동기 I/O 처리를 위한 강력한 도구입니다. 특히 asyncio.BufferedProtocol은 데이터를 버퍼링하여 효율적으로 처리하는 데 사용됩니다. 하지만 asyncio.protocols._feed_data_to_buffered_proto 함수 내부의 데이터 처리 방식에 잠재적인 성능 병목이 존재했습니다. 이 함수는 데이터를 버퍼에 복사하는 과정에서 반복적으로 슬라이싱(slicing)을 수행했는데, 이는 데이터 크기에 따라 제곱에 비례하는 시간 복잡도(O(N^2))를 야기할 수 있었습니다. 이번 PR은 이러한 비효율적인 데이터 슬라이싱을 제거하고, 오프셋(offset) 추적을 통해 시간 복잡도를 선형(O(N))으로 개선하는 중요한 최적화를 수행합니다.

코드 변경 분석

이번 최적화는 asyncio/protocols.py 파일의 _feed_data_to_buffered_proto 함수에 집중되어 있습니다. 기존 코드와 변경된 코드를 비교하며 어떤 부분이 어떻게 개선되었는지 살펴보겠습니다.

`asyncio/protocols.py`

기존 코드 (`Before`)

def _feed_data_to_buffered_proto(proto, data):
    data_len = len(data)
    while data_len:
        buf = proto.get_buffer(data_len)
        buf_len = len(buf)
        if not buf_len:
            raise RuntimeError('get_buffer() returned an empty buffer')

        if buf_len >= data_len:
            buf[:data_len] = data
            proto.buffer_updated(data_len)
            return
        else:
            buf[:buf_len] = data[:buf_len]
            proto.buffer_updated(buf_len)
            data = data[buf_len:]
            data_len = len(data)

기존 코드에서는 while 루프 안에서 data를 data[buf_len:]와 같이 슬라이싱하여 나머지 데이터를 계속 처리했습니다. 데이터가 클 경우, 이 슬라이싱 연산은 매번 새로운 바이트열 객체를 생성하게 되며, 이는 O(N)의 비용이 듭니다. 루프가 반복될 때마다 이 연산이 수행되므로 전체적으로 O(N^2)의 시간 복잡도를 가지게 됩니다.

변경된 코드 (`After`)

def _feed_data_to_buffered_proto(proto, data):
    data_len = len(data)
    start = 0
    while data_len:
        buf = proto.get_buffer(data_len)
        buf_len = len(buf)
        if not buf_len:
            raise RuntimeError('get_buffer() returned an empty buffer')

        if buf_len >= data_len:
            buf[:data_len] = data[start:] if start else data
            proto.buffer_updated(data_len)
            return
        else:
            buf[:buf_len] = data[start:start + buf_len]
            proto.buffer_updated(buf_len)
            start += buf_len
            data_len -= buf_len

변경된 코드에서는 start 변수를 도입하여 데이터의 시작 오프셋을 추적합니다. 더 이상 data = data[buf_len:]와 같이 원본 data를 직접 슬라이싱하여 변경하지 않습니다. 대신, data[start:] 또는 data[start:start + buf_len]와 같이 슬라이싱할 때 start 오프셋을 사용하여 원본 데이터의 일부분을 참조합니다. 루프가 반복될 때마다 start 오프셋만 증가시키고 data_len을 감소시켜 남은 데이터의 길이를 관리합니다. 이 방식은 매번 새로운 바이트열 객체를 생성하는 대신, 기존 data 객체 내에서 포인터(오프셋)만 이동시키는 것이므로 O(1)의 비용으로 처리할 수 있습니다. 결과적으로 전체 루프의 시간 복잡도는 O(N)으로 개선됩니다.

특히 buf[:data_len] = data[start:] if start else data 부분은 start가 0일 경우 (즉, 첫 번째 반복이거나 전체 데이터가 한 번에 버퍼에 들어가는 경우) 불필요한 슬라이싱을 피하기 위한 최적화입니다. 이는 일반적인 경우(start > 0)에만 data[start:]를 사용하도록 하여 효율성을 높입니다.

`Lib/test/test_asyncio/test_protocols.py`

이번 PR에서는 새로운 테스트 케이스인 FeedDataToBufferedProtoTests가 추가되었습니다. 이는 변경 사항이 올바르게 작동하는지 검증하기 위함입니다.

test_large_multi_iteration: 큰 데이터를 여러 번에 걸쳐 버퍼에 쓰는 시나리오를 테스트하여 오프셋 추적이 올바르게 작동하는지 확인합니다.
test_memoryview_input: memoryview 객체가 입력으로 주어졌을 때도 오프셋 추적이 잘 동작하는지 검증합니다. 이는 asyncio가 다양한 데이터 타입을 효율적으로 처리할 수 있음을 보여줍니다.

왜 이게 좋은가?

성능 향상

이 PR의 핵심은 _feed_data_to_buffered_proto 함수의 시간 복잡도를 O(N^2)에서 O(N)으로 개선한 것입니다. 이는 특히 대용량 데이터를 처리할 때 상당한 성능 향상을 가져옵니다. PR 설명에 포함된 벤치마크 스크립트(buffer_memory_view_bench.py)를 실행하면 다음과 같은 비교 결과를 얻을 수 있습니다 (실제 결과는 환경에 따라 다를 수 있습니다):

./python.exe -m pyperf compare_to old.json new.json --table

벤치마크 결과는 일반적으로 new 버전이 old 버전에 비해 훨씬 빠른 실행 시간을 보여줍니다. 예를 들어, 큰 데이터셋(1024 * 1024 바이트)과 큰 버퍼(65536 바이트)를 사용하는 시나리오에서는 수 배에서 수십 배의 성능 향상을 기대할 수 있습니다. 이는 네트워크 통신, 파일 I/O 등 대용량 데이터를 자주 다루는 asyncio 애플리케이션의 전반적인 성능을 향상시키는 데 기여합니다.

일반적인 교훈

슬라이싱의 비용 인지: 파이썬에서 문자열이나 바이트열의 슬라이싱은 새로운 객체를 생성하는 비용이 발생합니다. 특히 루프 안에서 반복적으로 슬라이싱하는 것은 O(N^2)의 시간 복잡도를 유발할 수 있으므로 주의해야 합니다.
오프셋 추적의 유용성: 데이터를 직접 슬라이싱하는 대신, 원본 데이터에 대한 시작 오프셋과 길이를 추적하는 방식은 메모리 할당을 줄이고 성능을 크게 향상시킬 수 있습니다. 이는 많은 저수준 데이터 처리 로직에서 유용한 패턴입니다.
memoryview 활용: memoryview는 데이터 복사 없이 메모리 버퍼에 접근할 수 있게 해주어 효율성을 높입니다. 이번 PR은 memoryview 입력에 대해서도 최적화가 잘 동작함을 보장했습니다.
테스트의 중요성: 새로운 최적화 로직이 추가될 때는 반드시 해당 로직을 충분히 커버하는 테스트 케이스를 작성해야 합니다. 특히 엣지 케이스(edge case)나 다양한 입력 타입에 대한 테스트는 버그를 예방하고 코드의 견고성을 높입니다.

리뷰 피드백 반영

주요 리뷰어인 deadlovelll님은 다음과 같은 사항들을 지적하고 개선을 요청했습니다:

PR 제목 형식: gh-XXXXXX 뒤에 콜론(:)을 붙이는 표준 형식을 따르도록 수정했습니다.
벤치마크 업데이트 및 NEWS 항목: 개선 사항을 보여주는 벤치마크 결과를 업데이트하고, 실제 사용 사례(call site)를 언급하는 NEWS 항목 추가를 제안했습니다. 이후 kumaraditya303님의 의견에 따라 NEWS 항목은 제외되었습니다.
테스트 케이스 추가: 변경 사항을 검증할 수 있는 테스트 케이스(FeedDataToBufferedProtoTests)를 추가했습니다.
Force-push 금지: 향후 기여 시에는 커밋 히스토리를 보존하기 위해 force-push를 지양하도록 안내받았습니다.

또한, kumaraditya303님은 코드 개선 과정에서 start=0일 때 불필요한 슬라이싱을 피하기 위한 조건문(if start else data)을 유지하는 것이 좋다는 의견을 제시했고, 이는 최종 코드에 반영되었습니다.

결론

이번 PR은 asyncio의 내부 데이터 처리 로직을 정밀하게 분석하여 O(N^2)의 잠재적 성능 병목을 O(N)으로 개선한 훌륭한 예시입니다. 슬라이싱 대신 오프셋을 추적하는 단순하지만 효과적인 기법을 통해, 특히 대용량 데이터를 다루는 비동기 애플리케이션의 효율성을 크게 향상시킬 수 있게 되었습니다. 이는 파이썬 코어 라이브러리의 지속적인 최적화 노력을 보여주는 좋은 사례이며, 개발자들에게 효율적인 데이터 처리 방법에 대한 귀중한 교훈을 제공합니다.

참고 자료

⚠️ 알림: 이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.

PR Analysis 의 다른글

이전글 [sglang] SGLang NGRAM 성능 최적화: 호스트 기반 트리 링크 유도로 GPU 병목 제거하기
현재글 : [cpython] asyncio 프로토콜 데이터 처리 최적화: O(N^2)에서 O(N)으로
다음글 [vllm] vLLM: PyNvVideoCodec 하드웨어 디코더 동시성 최적화로 비디오 처리량 94% 향상