Lewati ke konten

Tolok Ukur

Lihat sebagai Markdown Edit di GitHub Dokumentasi di d105217

Repositori ini memiliki rangkaian pengujian tolok ukur di bin/ dan benchmarks/. Rangkaian ini mengukur setiap mode pencarian pada korpus nyata (WordPress, Laravel) dan kumpulan data sintetis yang dihasilkan, merekam laporan terstruktur, serta memungkinkan Anda membandingkan dua rangkaian laporan.

Rangkaian pengujian ini merupakan bagian dari repositori, bukan dari paket Composer: 0.2.3, benchmarks/, dan skrip bin/bench* tidak disertakan dalam paket, jadi jalankan dari hasil kloning (git clone https://github.com/inline0/greph && cd greph && composer install).

Angka yang dipublikasikan dalam README bersumber dari proses GitHub Actions, bukan dari mesin lokal. Proses lokal berguna untuk iterasi; proses CI adalah sumber kebenaran.

Korpus

Korpus sintetis (synthetic-1k, synthetic-10k, synthetic-100k-single) dibuat di benchmarks/corpora/synthetic/ saat dijalankan pertama kali. Korpus nyata tidak disertakan: tempatkan hasil checkout di benchmarks/corpora/wordpress atau benchmarks/corpora/laravel (alur kerja CI mengkloning WordPress/WordPress dengan --depth=1). Korpus yang direktorinya tidak ada akan dilewati.

Menjalankan Tolok Ukur

Shell
# Full benchmark suite, every corpus that is present
./bin/bench

# Specific category (the category names used in benchmarks/suites/)
./bin/bench --category text
./bin/bench --category ast

# Compare against external tools when available
./bin/bench --compare rg,grep
./bin/bench --compare sg

# Choose a corpus
./bin/bench --corpus wordpress
./bin/bench --corpus laravel
./bin/bench --corpus synthetic-1k

# Write the run as JSON
./bin/bench --corpus wordpress --output build/run-1.json

# Measured series: 5 runs after 1 warmup run
./bin/bench-series --repeat 5 --warmup 1 --corpus wordpress --output build/head-series.json

# Aggregate separate runs into one series
./bin/bench-aggregate --output build/head-series.json build/run-*.json

bin/bench-compare base-series.json head-series.json membandingkan dua file rangkaian (keluaran dari bench-series atau bench-aggregate) dan mencetak ringkasan Markdown, berguna saat melakukan iterasi pada jalur yang sering dijalankan. bin/bench-ci memicu alur kerja Benchmark di GitHub Actions melalui gh CLI.

Kategori

README menerbitkan delapan kelompok hasil, yang masing-masing mengukur lapisan mesin tertentu. Setiap kelompok mengumpulkan satu atau beberapa kategori rangkaian pengujian yang ditentukan di benchmarks/suites/.

Mode Pemindaian: Teks

Pencarian teks native menggunakan pola literal, regex, dan gabungan. Baseline yang dipublikasikan dijalankan pada korpus WordPress dan mencakup:

  • Literal function
  • Literal tanpa membedakan huruf besar-kecil
  • Literal seluruh kata
  • Instans regex baru
  • Pemanggilan array regex
  • Literal awalan regex
  • Literal akhiran regex
  • Literal baris persis regex
  • Penggabungan literal regex

Mode Pemindaian: Penelusuran

Hanya menelusuri file, tanpa pencarian. Mengukur biaya penelusur yang memperhatikan gitignore secara tersendiri.

Mode Pemindaian: Teks Paralel

Pencarian string tetap untuk function dengan 1, 2, dan 4 pekerjaan. Untuk pola tersebut, kumpulan worker baru dimulai jika jumlah file melebihi jobs * 4_000 (lihat Worker Paralel), lebih banyak daripada jumlah dalam korpus WordPress. Karena itu, ketiga baris yang dipublikasikan berjalan dalam satu proses dan tidak menunjukkan penskalaan kumpulan worker (#8).

Mode Pemindaian: AST

Pencarian AST native menggunakan pola yang representatif:

  • new $CLASS()
  • array($$$ITEMS)

Mode Teks Terindeks

Pencarian teks terindeks yang sudah dihangatkan dengan pola yang sama seperti mode pemindaian. Mencakup kueri literal, tanpa membedakan huruf besar-kecil, seluruh kata, token pendek, dan regex.

Kueri Ringkasan Terindeks

Pencarian teks terindeks yang sudah dihangatkan menggunakan keluaran jumlah, file yang cocok, dan file yang tidak cocok. Kueri ini paling diuntungkan oleh penyimpanan postings karena pekerjaan per file paling ringan.

AST Terindeks / Tembolok

Pencarian fakta AST yang sudah dihangatkan dan pencarian AST dalam tembolok menggunakan pola yang sama seperti mode pemindaian AST.

Biaya Build

Biaya build dingin untuk indeks trigram, indeks fakta AST, dan tembolok AST. Berguna untuk menentukan mode mana yang perlu dipertahankan bagi beban kerja tertentu.

Membaca Angka yang Dipublikasikan

README menerbitkan cuplikan proses CI terbaru untuk setiap baseline. Setiap bagian bersumber dari proses GitHub Actions tertentu dan diberi label dengan korpus, runner, versi PHP, serta jumlah pengukuran dan pemanasan. Jika Anda perlu mereproduksi angka, gunakan kombinasi yang sama secara lokal.

Kolom perbandingan (rg, grep, sg) dikumpulkan dalam pekerjaan yang sama, pada runner yang sama, dan dengan korpus yang sama. Angka tersebut tidak diekstrapolasi dari tolok ukur eksternal.

Cara Menambahkan Tolok Ukur

  1. Tambahkan definisi tolok ukur di benchmarks/.
  2. Tambahkan skenario yang sesuai ke rangkaian regresi jika belum ada yang setara, agar perilaku yang diukur juga diverifikasi.
  3. Jalankan ./bin/bench --category <yours> untuk memvalidasi tolok ukur baru.
  4. Bandingkan dengan main menggunakan alur kerja Benchmark, yang berjalan pada pull request yang menyentuh src/, benchmarks/, atau bin/ dan mengirim perbandingan head dengan base dalam ringkasan proses.
  5. Perbarui tabel README setelah proses CI yang mencakup tolok ukur baru digabungkan ke main.

Prinsip Performa

Greph tidak berupaya mengungguli ripgrep atau grep dalam pemindaian dingin. Ripgrep diimplementasikan dalam Rust dengan pemindaian literal SIMD yang disetel secara manual, dan menurut angka yang dipublikasikan, rg maupun GNU grep lebih cepat daripada Greph pada setiap pemindaian teks dingin. Tujuannya berbeda:

  • Cukup cepat agar penggunaan interaktif dan siklus agen terasa native.
  • Menjawab kueri berulang dari indeks yang sudah dihangatkan: regex terindeks serta kueri jumlah dan daftar file terindeks lebih cepat daripada pemindaian rg maupun grep pada pohon yang sama.
  • Mengungguli ast-grep pada beban kerja AST terindeks dan dalam tembolok, karena tembolok hangat milik Greph menghindari penguraian ulang pohon. Pencarian AST dingin memberikan hasil beragam: new $CLASS() lebih cepat daripada sg, sedangkan array($$$ITEMS) lebih lambat.
  • Memastikan setiap peningkatan performa dapat diukur dan direproduksi.

Klaim performa yang tidak didukung laporan tolok ukur tidak akan digabungkan.