Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Separating benchmarks with different complexity and benchmarks with just variants

Ouverte
#190 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Documentation
Clarté
À clarifier
Activité
À l'abandon
Stack technique
ruby

Piste de recherche

Commencez par examiner les exemples de benchmark du dépôt, notamment l’exemple lié Array#bsearch versus Array#find, et comparez les résultats de CRuby aux benchmarks de TruffleRuby référencés. La réalisation doit distinguer les résultats déterminés par la complexité des variantes sensibles à l’implémentation et ajouter les réserves proposées, mais l’issue n’identifie ni fichiers ni tests.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Ruby
Étoiles
5.7k
Forks
370
Merge moyen
4 h 42 min
PR mergées (30 j)
13

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de fastruby/fast-ruby

Toutes les issues de fastruby/fast-ruby

Issues similaires

Plus d'issues Ruby

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.