GN⁺: Ruby의 JSON 최적화, Part 1

사실 대안이 필요하지 않음

• 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% 개선함.

계속될 이야기

• 더 많은 최적화가 있지만, 다음 글에서 다룰 예정임.

[neo]

Hacker News 의견

• 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와의 호환성도 궁금함