Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Separating benchmarks with different complexity and benchmarks with just variants

Abierto
#190 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
ruby
Área
documentation, performance

Línea de trabajo

Comienza revisando los ejemplos de benchmark del repositorio, incluido el ejemplo enlazado de Array#bsearch frente a Array#find, y compara los resultados de CRuby con los benchmarks de TruffleRuby mencionados. La implementación debe separar los resultados determinados por la complejidad de las variantes sensibles a la implementación y añadir las salvedades propuestas, pero el issue no identifica archivos ni tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hello there,
I think it would be worthwhile to separate the example in two categories:

  • Benchmarks which are faster due to the variants having different complexity (for example, https://github.com/JuanitoFatas/fast-ruby#arraybsearch-vs-arrayfind-code). Those I believe will remain with a clear advantage for one of the variants for a long time.
  • Other benchmarks, where the difference is minimal, and highly relies on the specific Ruby implementation and version, and where the slow and fast variants might switch regularly.

I think the second category deserves a clear warning that those results were measured on some version of CRuby and might not apply anymore, and likely do not apply to other Ruby implementations.

For fun, @gogainda ran these benchmarks on TruffleRuby at https://github.com/gogainda/fast-truffleruby
What I can see from a quick look is many of the differences on MRI don't exist on TruffleRuby (e.g., Sequential vs Parallel Assignment).
Also, many of these micro benchmarks optimize away (>1 billion i/s), i.e., in other words doing that operation alone costs basically nothing or like <10 cycles, which I interpret as a useful word of caution against microbenchmarks which might test something real code wouldn't, and might show differences that don't matter in practice.
I'd recommend in general to benchmark in the setup of your app/program, on the machine where the performance will matter. For example, a variant might give be 25% faster in a microbenchmark, but yield a 0% speedup on the full app and therefore be of limited value.

Lenguaje dominante
Ruby
Estrellas
5.7k
Forks
370
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fastruby/fast-ruby

Todos los issues de fastruby/fast-ruby

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.