답변

Rust에서는 컴파일러가 메모리에서 데이터를 효율적으로 배치하기 위해 정렬 및 구조체 및 enum 레이아웃에 대한 지식을 사용합니다. 이 질문은 저수준 및 시스템 개발에서 타입의 과도한 크기가 메모리 낭비로 이어지는 경우 특히 중요합니다.

문제 역사

구조체의 자동 정렬은 대부분의 언어에서 특징적이지만, Rust에서는 컴파일러가 레이아웃에 대한 엄격한 보장을 제공하고(최적화를 허용) enum의 경우 최대 크기에 따라 모든 변수를 위한 메모리를 통합하여 컴팩트한 저장을 구현합니다.

문제

구조체나 enum의 필드 순서 및 타입은 정렬 특성으로 인해 최종 타입의 크기에 영향을 미칩니다. 잘못된 순서는 "패딩" — 사용되지 않는 바이트를 증가시킵니다. 연관된 데이터를 가진 enum의 경우 최대 옵션이 크기를 결정하며, 일부 구조체는 enum을 예기치 않게 부풀릴 수 있습니다.

해결책

필드의 순서를 정확히 지정하고 타입을 선택하며, std::mem::size_of를 통해 데이터 크기를 분석합니다. enum의 경우 중첩된 구조체 및 포인터에 주의해야 합니다.

코드 예:

struct Bad {
    a: u8,  // 1바이트 + 7바이트 패딩
    b: u64, // 8바이트
}

struct Good {
    b: u64, // 8바이트, 처음부터 정렬
    a: u8,  // 1바이트 + 끝에 7바이트 패딩
}

크기 확인:

use std::mem::size_of;
println!("{}", size_of::<Bad>());  // 16바이트
println!("{}", size_of::<Good>()); // 16바이트 (단, 패딩은 이제 끝에 있음)

enum의 경우:

enum Example {
    Unit,
    Num(u32),
    Pair(u64, u8),
}
println!("{}", size_of::<Example>()); // 크기 — max(변수 크기) + discriminant

주요 특징:

필드 순서와 정렬은 메모리 레이아웃에 매우 중요합니다.
enum의 크기는 가장 큰 옵션의 크기와 discriminant에 의해 결정됩니다.
중첩된 구조체와 enum 내의 enum은 크기를 부풀릴 수 있습니다.

트릭 질문들.

구조체에서 u8과 u64의 순서를 바꾼다면 구조체의 크기가 변화할까요?

아니요, 전체 크기는 여전히 최대 필드의 정렬에 의해 나누어지지만 패딩은 이동합니다. 이는 구조체가 다른 구조체에 포함되거나 FFI에 전달될 경우 중요합니다.

작은 enum이 큰 메모리 크기를 가질 수 있을까요?

네, 하나의 옵션이 큰 객체나 참조를 포함하는 경우, 전체 enum 크기는 가장 "무거운" 옵션의 크기와 discriminant에 해당합니다.

구조체의 레이아웃은 항상 모든 플랫폼에서 동일한가요?

아니요, 레이아웃과 정렬은 아키텍처에 따라 다를 수 있습니다. 엄격한 제어를 위해 #[repr(C)] 속성을 사용합니다.

#[repr(C)]
struct MyFFIStruct {
    x: u32,
    y: u8,
}

일반적인 오류 및 안티 패턴

작은 사이즈 사이에 큰/비정렬된 타입을 포함하여 패딩을 늘리기
큰 중첩 객체를 포함한 enum을 맹목적으로 포함하기
FFI에서 #[repr(C)] 누락하기

실제 사례

부정적 사례

대형 컬렉션에서 드물게 사용되는 Vec를 포함한 enum이 있어 enum의 크기를 10배 증가시킵니다. 메모리가 헛되이 낭비됩니다.

장점:

쉽게 구현 가능; 패턴 매칭이 쉬움

단점:

메모리 낭비가 커지고 성능 저하

긍정적 사례

enum을 여러 개의 작은 enum으로 나누고 배열/컬렉션은 별도로 저장하거나 드문 옵션에 대해 Box를 통해 저장하며, 레이아웃은 #[repr(C)]를 통해 제어합니다. size_of를 통해 크기를 확인합니다.