Otimização de JSON no Ruby, Parte 1

Na verdade, não é preciso uma alternativa

• ruby/json é um pouco mais lento que oj, mas a diferença não é grande.
• oj é popular por causa do desempenho, mas pode causar vários problemas.
• Um dos problemas do oj é uma questão de segurança causada por monkey patching via Oj.mimic_JSON.

A responsabilidade do monkey patching

• Oj.mimic_JSON e Oj.optimize_rails substituem implementações menos eficientes de JSON, mas podem causar problemas.
• Por exemplo, podem ignorar a opção script_safe, deixando o sistema vulnerável a ataques XSS.
• Monkey patching deve ser feito com cuidado e precisa lidar com segurança com a evolução da API.

Instabilidade

• oj foi uma das principais causas de crashes do Ruby em operações de grande escala.
• oj é desenvolvido de forma muito ativa, então novos crashes acontecem com frequência.
• Havia hacks sujos na base de código do oj em que era difícil confiar.

Trabalho de base

• A ideia é melhorar ruby/json para alcançar um desempenho próximo ao do oj e reduzir a necessidade de monkey patching.
• Benchmarks foram configurados e um profiler em C foi usado para analisar o desempenho.

Evitando verificações duplicadas

• O desempenho foi melhorado no benchmark de JSON.dump ao evitar verificações UTF-8 duplicadas.
• Remover o trabalho redundante entre rb_enc_str_asciionly_p e isLegalUTF8 trouxe um ganho de desempenho de 3%.

Verificar primeiro as condições mais baratas e mais prováveis

• A otimização da condição que verifica se o buffer já foi alocado na função fbuffer_inc_capa trouxe um ganho de desempenho de 15%.

Reduzindo o custo de configuração

• Reduzir o custo de configuração de ruby/json melhorou bastante o desempenho em microbenchmarks.

Evitando pointer chasing

• Remover a chamada de rb_enc_get melhorou o desempenho em 8%.

Tabela de consulta

• O uso de uma tabela de consulta melhorou em 30% o desempenho do dump de strings JSON.

Continua

• Há mais otimizações, mas elas serão abordadas no próximo artigo.

[GN⁺]

Comentários do Hacker News

• O uso padrão do jbuilder no Rails é um dos fatores que tornam a renderização de JSON lenta

  • Renderizar muitas partes com jbuilder deixa tudo mais lento

• Fiquei curioso se há alguma informação sobre o tempo que a nova versão leva para fazer parse/encode do dump JSON do Twitter

• O artigo sobre esse tema é muito fácil de entender e dá vontade de fazer benchmark e otimizar código Ruby

  • Agradecimentos ao autor

• Excelente artigo e trabalho

  • Fico me perguntando se ainda há motivo para usar Oj daqui para frente

• Artigo muito interessante

  • Fico curioso por que, em otimizações que não se limitam ao Ruby, como usar uma lookup table para caracteres de escape, não se aproveita uma biblioteca já existente como simdjson

• Adoro o trabalho do byroot

  • Sempre me impressionam suas contribuições e produtividade
  • Gostaria de participar do trabalho do Ruby-core, mas perco a motivação por não encontrar algo compatível com minhas habilidades
  • Se as pessoas que trabalham com Ruby em C escrevessem com mais frequência, haveria mais gente com as habilidades necessárias para melhorar ainda mais o Ruby

• O conselho sobre profiler em C foi excelente

  • Deu vontade de tentar otimizar de novo adicionando código C a uma gem Ruby

• O truque de performance chamado "lookup table" usado no PR do Mame foi impressionante

  • Usar String#each_codepoint em vez de String#each_char pode reduzir a carga no GC

• Compartilhou um exemplo de como melhorou ainda mais a performance na própria base de código

  • Usou Array#pack para coletar code points e converter em String

• Em CPUs modernas, dicas de branch prediction não são úteis

• Fico curioso se o JSON do Ruby usa intrinsics

  • Também tenho curiosidade sobre a compatibilidade com diferentes JITs