Rails enum 메서드 생성 방식이 처리량을 높였다

Rails의 열거형(enum) 메서드 생성 방식을 바꾸자는 제안에서 처리량이 크게 뛰었습니다. 글의 마이크로벤치마크에서 일반 Ruby는 초당 1.721M회에서 3.145M회로, YJIT는 3.568M회에서 16.274M회로 올랐습니다. ZJIT도 3.812M회에서 18.509M회로 높아졌습니다. 저는 특히 YJIT와 ZJIT에서 네 배 넘는 차이가 난 점이 오래 남습니다. 메서드 생성 방식만으로 실행량이 이렇게 달라질 수 있다는 사실이 놀랍습니다.

ruby-enum 관리자는 벤치마크로 상속에 따른 조회 성능 저하를 찾아 고쳤습니다. 이 사례와 나란히 보면, Ruby의 성능 개선은 작은 호출·조회 경로를 재는 일에서 시작합니다. 이번 Rails 제안도 메서드 생성 방식을 바꾸고 마이크로벤치마크로 차이를 드러냅니다.

기존 구현은 메서드 블록 안에서 동적 호출을 하고 enum 값을 바깥 환경에서 가져왔습니다. 제안은 생성된 메서드에서 직접 호출하도록 바꿉니다. enum 값까지 생성된 코드 안에 넣어 바깥 환경을 다시 찾지 않게 한 점도 반갑습니다.

다만 shippable? 하나를 잰 마이크로벤치마크라 실제 앱 요청도 같은 배수로 빨라진다는 뜻은 아닙니다. 구현은 module_eval을 직접 부르지 않고 ActiveSupport::CodeGenerator로 코드를 생성합니다. enum 항목 이름이 루비 식별자가 아니거나 부동소수점 값의 저장과 복원 과정이 있다면, 그 동작도 맞아야 합니다. 앱의 enum 구성과 해당 메서드의 호출 빈도에 따라 이 수치가 선택을 바꿀 수도, 그렇지 않을 수도 있습니다.

먼저 앱에서 enum 메서드가 반복 호출되는 경로를 프로파일러로 찾아보십시오. PR을 별도 작업공간에서 시험할 수 있다면 해당 경로의 처리량을 전후로 재 보십시오. 비식별자 이름이나 부동소수점 값도 사용한다면, 그 경우에도 동작이 유지되는지 확인하십시오.

실제 호출 경로의 처리량 측정과 특이한 enum 값의 호환성 시험 가운데 무엇부터 하시겠습니까?