# Ruby의 JSON 최적화, Part 1

> Clean Markdown view of GeekNews topic #18337. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18337](https://news.hada.io/topic?id=18337)
- GeekNews Markdown: [https://news.hada.io/topic/18337.md](https://news.hada.io/topic/18337.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-12-19T10:02:07+09:00
- Updated: 2024-12-19T10:02:07+09:00
- Original source: [byroot.github.io](https://byroot.github.io/ruby/json/2024/12/15/optimizing-ruby-json-part-1.html)
- Points: 1
- Comments: 1

## Topic Body

### 사실 대안이 필요하지 않음  
- `ruby/json`은 `oj`보다 약간 느리지만, 차이는 크지 않음.  
- `oj`는 성능 때문에 인기가 많지만, 여러 문제를 일으킬 수 있음.  
- `oj`의 문제점 중 하나는 `Oj.mimic_JSON`을 통한 원숭이 패치로 인해 발생하는 보안 문제임.  
  
### 몽키 패치의 책임  
- `Oj.mimic_JSON`과 `Oj.optimize_rails`는 JSON의 덜 효율적인 구현을 대체하지만, 문제가 발생할 수 있음.  
- 예를 들어, `script_safe` 옵션을 무시하여 XSS 공격에 취약해질 수 있음.  
- 몽키 패치는 신중하게 수행되어야 하며, API의 진화에 따라 안전하게 대처해야 함.  
  
### 불안정성  
- `oj`는 대규모 운영에서 루비 충돌의 주요 원인 중 하나였음.  
- `oj`는 매우 활발히 개발되고 있어 새로운 충돌이 자주 발생함.  
- `oj`의 코드베이스에는 신뢰하기 어려운 더러운 해킹이 존재했음.  
  
### 기초 작업  
- `ruby/json`을 `oj`와 비슷한 성능으로 개선하여 원숭이 패치의 필요성을 줄이고자 함.  
- 벤치마크를 설정하고 C 프로파일러를 사용하여 성능을 분석함.  
  
### 중복 검사 피하기  
- `JSON.dump` 벤치마크에서 중복된 UTF-8 검사를 피하여 성능을 개선함.  
- `rb_enc_str_asciionly_p`와 `isLegalUTF8`의 중복 작업을 제거하여 3%의 성능 향상을 이룸.  
  
### 더 저렴하고 가능성이 높은 조건 먼저 확인  
- `fbuffer_inc_capa` 함수에서 버퍼가 이미 할당되었는지 확인하는 조건을 최적화하여 15%의 성능 향상을 이룸.  
  
### 설정 비용 줄이기  
- `ruby/json`의 설정 비용을 줄여 마이크로 벤치마크에서 성능을 크게 개선함.  
  
### 포인터 추적 피하기  
- `rb_enc_get` 호출을 제거하여 성능을 8% 개선함.  
  
### 조회 테이블  
- 조회 테이블을 사용하여 JSON 문자열 덤프의 성능을 30% 개선함.  
  
### 계속될 이야기  
- 더 많은 최적화가 있지만, 다음 글에서 다룰 예정임.

## Comments



### Comment 32524

- Author: neo
- Created: 2024-12-19T10:02:07+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=42446846) 
- Rails의 기본 jbuilder 사용은 JSON 렌더링을 느리게 만드는 요인 중 하나임
  - 많은 부분을 jbuilder로 렌더링하면 속도가 느려짐

- 새로운 버전이 Twitter JSON 덤프를 파싱/인코딩하는 데 걸리는 시간에 대한 정보가 있는지 궁금함

- 이 주제에 대한 글이 매우 쉽게 이해되며, Ruby 코드를 벤치마크하고 최적화하고 싶어짐
  - 작성자에게 감사함

- 훌륭한 글과 작업임
  - 앞으로 Oj를 사용할 이유가 있는지 궁금함

- 매우 재미있는 글임
  - Ruby에 국한되지 않은 최적화, 예를 들어 escape 문자에 대한 조회 테이블을 사용할 때, 이미 존재하는 simdjson 같은 라이브러리를 활용하지 않는 이유가 궁금함

- byroot의 작업을 사랑함
  - 그의 기여와 생산성에 항상 놀람
  - Ruby-core 작업에 참여하고 싶지만, 자신의 기술에 맞는 것을 찾지 못해 동기부여가 떨어짐
  - Ruby C 관련 사람들이 더 자주 글을 쓴다면 Ruby를 더 발전시킬 수 있는 기술을 가진 사람들이 많아질 것임

- C 프로파일러 조언이 훌륭했음
  - Ruby gem에 C 코드를 추가하여 최적화를 다시 시도해보고 싶음

- Mame의 PR에서 사용된 "lookup table"이라는 성능 트릭이 인상적이었음
  - `String#each_char` 대신 `String#each_codepoint`를 사용하면 GC 부담을 줄일 수 있음

- 자신의 코드베이스에서 성능을 더 향상시킨 예시를 공유함
  - `Array#pack`을 사용하여 코드포인트를 수집하고 `String`으로 변환함

- 현대 CPU에서는 분기 예측 힌트가 쓸모없음

- Ruby JSON이 intrinsic을 사용하는지 궁금함
  - 다양한 JIT와의 호환성도 궁금함