Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Separating benchmarks with different complexity and benchmarks with just variants

Aperta
#190 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
ruby
Ambito
documentation, performance

Direzione di ricerca

Inizia esaminando gli esempi di benchmark del repository, incluso l'esempio collegato Array#bsearch versus Array#find, e confronta i risultati di CRuby con i benchmark di TruffleRuby indicati. L'implementazione dovrebbe separare i risultati determinati dalla complessità dalle varianti sensibili all'implementazione e aggiungere le cautele proposte, ma l'issue non identifica file o test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Ruby
Stelle
5.7k
Fork
370
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di fastruby/fast-ruby

Tutte le issue di fastruby/fast-ruby

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.