이 글에서는 Setting 클래스를 예시로 들어 일반 해시 조회와 메모이제이션된 해시 조회의 성능을 비교합니다. 첫 번째 벤치마크에서는 ‘type’ 키가 존재하는 경우를 살펴보았습니다. 메모이제이션된 type_memoized 메서드가 일반 type 메서드보다 약 1.31배 빠른 성능을 보였습니다. 그러나 실제 메서드 호출당 시간 차이는 20나노초 미만으로 매우 작았으며, 이는 수천 번 반복 호출되지 않는 이상 코드의 병목 현상이 될 가능성이 거의 없음을 시사합니다.
두 번째 벤치마크는 존재하지 않는 키를 조회하는 경우를 다룹니다. 이 시나리오에서는 오히려 메모이제이션된 버전이 일반 버전에 비해 약 1.2배 느려지는 결과가 나타났습니다. 이는 nil이 반환될 때마다 캐시 미스(cache miss)가 발생하여 메모이제이션의 이점을 얻지 못하고 추가적인 오버헤드만 발생하기 때문입니다. 비록 @type이 정의되었는지 확인하는 if defined?(@type) 패턴을 사용하여 이 문제를 해결할 수 있지만, 이 경우 메서드 로직의 절반 이상이 메모이제이션 로직으로 채워져 코드의 복잡성이 증가하는 단점이 있습니다.
마지막으로 중첩된 해시(Nested Hash) 조회의 경우를 벤치마크했습니다. 중첩된 키를 메모이제이션했을 때 약 1.6배의 성능 향상을 보였습니다. 이는 단일 레벨 해시 조회보다 성능 향상 폭이 크지만, 여전히 나노초 단위의 미미한 차이입니다.
종합적으로 볼 때, Ruby의 해시 조회는 언어 레벨에서 이미 매우 잘 최적화되어 있어 나노초 단위의 빠른 속도를 자랑합니다. 따라서 인스턴스 변수 조회를 통한 메모이제이션이 가져오는 성능 이점은 미미하며, 존재하지 않는 키를 조회하는 경우에는 오히려 성능 저하를 초래할 수 있습니다.