[uv] Interning을 통한 uv의 Simple API 파싱 최적화: 메모리와 속도 두 마리 토끼 잡기

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

PR 링크: astral-sh/uv#20104 상태: Merged | 변경: +301 / -132

들어가며

Python 패키지 매니저인 uv는 속도에 미친(?) 도구로 잘 알려져 있습니다. 하지만 성능 최적화에는 끝이 없죠. 최근 uv 메인 레포지토리에 병합된 Intern requires-python specifiers in Simple API parsing PR은 매우 흥미로운 최적화 기법을 보여줍니다.

이 PR이 해결하고자 하는 문제는 Simple API 응답의 중복성입니다. PyPI와 같은 인덱스 서버에서 특정 패키지(예: numpy)의 정보를 가져올 때, 수천 개의 파일(wheel, sdist) 목록이 반환됩니다. 그런데 이 파일들 중 상당수는 동일한 requires-python 값(예: >=3.9)을 가집니다. 기존의 uv는 이 값이 나타날 때마다 매번 독립적으로 파싱하고 메모리를 할당했습니다.

이번 글에서는 Interning 기법을 통해 어떻게 메모리 사용량을 10% 줄이고 파싱 성능을 개선했는지 코드 수준에서 분석해 보겠습니다.

코드 분석: 무엇이 바뀌었나?

1. 데이터 구조의 변화: `Arc`를 통한 공유

가장 먼저 눈에 띄는 변화는 requires-python 정보를 담는 구조체입니다. 기존에는 각 File 객체가 VersionSpecifiers를 직접 소유했지만, 이제는 Arc(Atomic Reference Counted)를 통해 공유합니다.

Before (crates/uv-distribution-types/src/file.rs)

pub struct File {
    pub filename: SmallString,
    pub hashes: HashDigests,
    pub requires_python: Option<VersionSpecifiers>,
    // ...
}

After (crates/uv-distribution-types/src/file.rs)

pub struct File {
    pub filename: SmallString,
    pub hashes: HashDigests,
    pub requires_python: Option<Arc<VersionSpecifiers>>,
    // ...
}

Arc를 사용함으로써 동일한 버전 명세서가 수천 번 등장하더라도, 메모리상에는 단 하나의 VersionSpecifiers 객체만 존재하고 나머지는 이를 가리키는 포인터만 가지게 됩니다.

2. `RequiresPythonInterner` 도입

중복된 문자열을 효율적으로 관리하기 위해 RequiresPythonInterner라는 헬퍼 구조체가 도입되었습니다. 이 구조체는 내부적으로 FxHashMap을 사용하여 이미 파싱된 결과를 캐싱합니다.

New Logic (crates/uv-client/src/html.rs)

#[derive(Default)]
struct RequiresPythonInterner {
    values: FxHashMap<SmallString, RequiresPythonResult>,
}

impl RequiresPythonInterner {
    fn parse(&mut self, value: &str) -> RequiresPythonResult {
        // 이미 파싱된 적이 있다면 캐싱된 Arc를 클론하여 반환 (포인터 복사)
        if let Some(requires_python) = self.values.get(value) {
            return requires_python.clone();
        }

        // 처음 보는 값이라면 파싱 후 Arc로 감싸서 저장
        let requires_python = LenientVersionSpecifiers::from_str(value)
            .map(VersionSpecifiers::from)
            .map(Arc::new);
        self.values
            .insert(SmallString::from(value), requires_python.clone());
        requires_python
    }
}

이 인터너는 HTML 파싱이나 JSON 역직렬화 과정에서 사용되어, 동일한 문자열에 대해 단 한 번의 파싱 작업만 수행되도록 보장합니다.

3. JSON 역직렬화 최적화

PyPI의 JSON 응답을 처리할 때도 이 기법이 적용되었습니다. serde를 이용한 역직렬화 과정에서 상태(Interner)를 유지하기 위해 deserialize_with 속성이 사용되었습니다.

After (crates/uv-pypi-types/src/simple_json.rs)

#[derive(Deserialize)]
pub struct PypiSimpleDetail {
    // ...
    #[serde(deserialize_with = "deserialize_pypi_files")]
    pub files: Vec<PypiFile>,
}

/// 파일 목록을 역직렬화하면서 각 requires-python 값을 단 한 번만 파싱합니다.
fn deserialize_pypi_files<'de, D>(deserializer: D) -> Result<Vec<PypiFile>, D::Error>
where
    D: Deserializer<'de>,
{
    let files = Vec::<PypiFileWire<'de>>::deserialize(deserializer)?;
    let mut interner = RequiresPythonInterner::default();
    Ok(files
        .into_iter()
        .map(|file| file.into_file(&mut interner))
        .collect())
}

여기서 PypiFileWire는 네트워크에서 받은 원본 데이터를 잠시 담아두는 중간 구조체입니다. 이후 into_file 메서드에서 인터너를 거쳐 최종적인 PypiFile로 변환됩니다.

4. 캐시 버전 업데이트

데이터 구조(VersionSpecifiers -> Arc<VersionSpecifiers>)가 변경되었으므로, 기존 캐시와의 호환성이 깨집니다. 이를 위해 uv는 캐시 버전을 명시적으로 올렸습니다.

Changes (crates/uv-cache/src/lib.rs)

-            Self::FlatIndex => "flat-index-v2",
+            Self::FlatIndex => "flat-index-v3",
-            Self::Simple => "simple-v21",
+            Self::Simple => "simple-v22",

왜 이게 좋은 최적화인가?

1. 실질적인 성능 향상

PR 설명에 따르면, 4,056개의 파일을 가진 NumPy의 Simple API 응답(약 2.65 MB JSON)을 처리할 때 다음과 같은 개선이 확인되었습니다.

실행 속도: uv pip compile 기준 약 2.3% ~ 4.0% 빨라졌습니다.
메모리/캐시 효율: 아카이브된 캐시 파일의 크기가 2.51 MB에서 2.26 MB로 약 10% 감소했습니다.

단순히 문자열 몇 개를 공유하는 것만으로도 수천 개의 객체가 생성되는 오버헤드를 줄여 유의미한 차이를 만들어낸 것입니다.

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

PR Analysis 의 다른글

이전글 [flashinfer] FlashInfer의 새로운 TGV GEMM 백엔드: CuTeDSL을 활용한 Blackwell 최적화
현재글 : [uv] Interning을 통한 uv의 Simple API 파싱 최적화: 메모리와 속도 두 마리 토끼 잡기
다음글 [vllm] vLLM의 Dynamic Speculative Decoding을 위한 Full CUDA Graph 최적화