Optimización de JSON en Ruby, Parte 1

En realidad no hace falta una alternativa

• ruby/json es un poco más lento que oj, pero la diferencia no es grande.
• oj es popular por su rendimiento, pero puede causar varios problemas.
• Uno de los problemas de oj es un tema de seguridad provocado por el monkey patch mediante Oj.mimic_JSON.

La responsabilidad del monkey patch

• Oj.mimic_JSON y Oj.optimize_rails reemplazan implementaciones menos eficientes de JSON, pero pueden generar problemas.
• Por ejemplo, pueden ignorar la opción script_safe, lo que puede dejarlo vulnerable a ataques XSS.
• Los monkey patches deben aplicarse con cuidado y manejarse de forma segura conforme evoluciona la API.

Inestabilidad

• oj fue una de las principales causas de crashes de Ruby en operaciones a gran escala.
• oj se desarrolla de forma muy activa, por lo que aparecen nuevos crashes con frecuencia.
• En el codebase de oj había hacks sucios difíciles de considerar confiables.

Trabajo de base

• La idea es mejorar ruby/json hasta acercarlo al rendimiento de oj y así reducir la necesidad de monkey patches.
• Se configuraron benchmarks y se usó un profiler de C para analizar el rendimiento.

Evitar verificaciones duplicadas

• En el benchmark de JSON.dump, se mejoró el rendimiento evitando verificaciones UTF-8 duplicadas.
• Al eliminar el trabajo redundante entre rb_enc_str_asciionly_p e isLegalUTF8, se logró una mejora de rendimiento del 3%.

Verificar primero las condiciones más baratas y más probables

• En la función fbuffer_inc_capa, se optimizó la condición que comprueba si el búfer ya estaba asignado, logrando una mejora de rendimiento del 15%.

Reducir el costo de configuración

• Al reducir el costo de configuración de ruby/json, el rendimiento mejoró mucho en microbenchmarks.

Evitar seguir punteros

• Al eliminar la llamada a rb_enc_get, el rendimiento mejoró un 8%.

Tabla de consulta

• Usar una tabla de consulta mejoró en 30% el rendimiento del volcado de cadenas JSON.

Continuará

• Hay más optimizaciones, pero se cubrirán en el siguiente artículo.

[GN⁺]

Comentarios de Hacker News

• El uso predeterminado de jbuilder en Rails es uno de los factores que vuelve más lento el renderizado de JSON

  • Renderizar muchas partes con jbuilder lo hace más lento

• Se preguntan si hay información sobre cuánto tiempo tarda la nueva versión en parsear/codificar el volcado JSON de Twitter

• El artículo sobre este tema es muy fácil de entender y da ganas de hacer benchmarks y optimizar código Ruby

  • Agradecen al autor

• Es un excelente artículo y trabajo

  • Se preguntan si todavía habrá motivos para usar Oj en el futuro

• Es un artículo muy interesante

  • Se preguntan por qué, en optimizaciones no limitadas a Ruby, como al usar tablas de búsqueda para caracteres de escape, no se aprovechan bibliotecas ya existentes como simdjson

• Les encanta el trabajo de byroot

  • Siempre les sorprenden sus contribuciones y productividad
  • Quieren participar en el trabajo de Ruby-core, pero se desmotivan porque no encuentran algo que se ajuste a sus habilidades
  • Si más gente relacionada con Ruby C escribiera con más frecuencia, habría más personas con las habilidades para hacer avanzar Ruby

• El consejo sobre perfiles en C fue excelente

  • Quieren volver a intentar optimizaciones agregando código C a una gem de Ruby

• Les impresionó el truco de rendimiento llamado "lookup table" usado en el PR de Mame

  • Usar String#each_codepoint en lugar de String#each_char puede reducir la carga del GC

• Comparten un ejemplo de cómo mejoraron aún más el rendimiento en su propia base de código

  • Usan Array#pack para recopilar codepoints y convertirlos en String

• En los CPU modernos, las pistas de predicción de ramas no sirven de mucho

• Se preguntan si Ruby JSON usa intrinsics

  • También tienen curiosidad sobre la compatibilidad con varios JITs