Snapshot pengukuran · 28 Oktober 2026Measurement snapshot · 28 October 2026
Hasil berikut memakai benchmark yang sudah dijalankan. Angka ditampilkan apa adanya beserta kondisi pengukuran dan batasnya. Ini snapshot bertanggal, bukan pengukuran ulang otomatis untuk perubahan kode setelah tanggal tersebut.These results come from benchmarks already run. The figures are shown as recorded, with their measurement conditions and limits. This is a dated snapshot, not an automatic remeasurement of code changes made afterward.
01 · Program CLI01 · CLI programs
Setiap pengukuran menjalankan proses baru dari start sampai exit. Median berasal dari 7 sampel untuk tujuh workload; waktu startup runtime ikut dihitung.Each measurement launches a fresh process and times it from start to exit. The medians below use 7 samples per workload; runtime startup is included.
YAZA belum menjadi yang tercepat pada workload core ini. Go lebih cepat pada 7 dari 7 workload dan Nim pada 6 dari 7. YAZA lebih cepat daripada C#/.NET, Python, JavaScript, Ruby, Java, PHP, dan Kotlin pada semua workload yang diuji. Ini hasil CLI proses-baru, bukan ukuran performa server.YAZA is not the fastest in this core workload set. Go is faster in 7 of 7 workloads and Nim in 6 of 7. YAZA is faster than C#/.NET, Python, JavaScript, Ruby, Java, PHP, and Kotlin in every tested workload. These are fresh-process CLI timings, not server performance.
R tidak masuk tabel karena Rscript tidak tersedia saat benchmark; implementasi R tetap ada di lampiran kode laporan.R is not in the table because Rscript was unavailable during the benchmark; its implementation is still included in the report's code appendix.
Geser tabel ke samping untuk melihat semua bahasa.Scroll the table horizontally to see every language.
| WorkloadWorkload | YAZA | .NET C# | Python | JavaScript | Ruby | Java | PHP | Go | Nim | Kotlin/JVM |
|---|---|---|---|---|---|---|---|---|---|---|
| Hello World · proses mulaiHello World · process start | 3.277 | 23.201 | 13.556 | 39.259 | 28.864 | 27.057 | 42.280 | 2.321 | 1.734 | 43.530 |
| Cetak 50.000 barisPrint 50,000 lines | 5.564 | 53.871 | 21.917 | 79.185 | 35.710 | 78.941 | 61.900 | 4.121 | 5.521 | 81.404 |
| Jumlahkan 10 juta integerSum 10 million integers | 6.454 | 33.712 | 358.907 | 92.773 | 147.852 | 38.089 | 71.232 | 5.789 | 6.447 | 42.786 |
| Fibonacci rekursif · 34Recursive Fibonacci · 34 | 17.440 | 39.430 | 769.832 | 76.124 | 315.006 | 40.252 | 217.411 | 16.204 | 27.420 | 46.217 |
| Hitung bilangan prima · sampai 100.000Prime count · up to 100,000 | 5.704 | 28.235 | 108.911 | 48.491 | 84.493 | 34.152 | 58.679 | 4.445 | 4.385 | 39.641 |
| Angka ke teks + panjang · 250.000Number to text + length · 250,000 | 16.313 | 30.804 | 42.286 | 45.251 | 37.375 | 47.288 | 45.484 | 5.042 | 4.768 | 51.057 |
| Buat + pindai list 64 itemCreate + scan 64-item list | 4.306 | 30.831 | 73.175 | 47.864 | 72.441 | 36.974 | 50.658 | 2.949 | 2.526 | 47.355 |
Workload lain menjumlahkan 1 sampai 10 juta, menghitung Fibonacci rekursif sederhana untuk 34, menghitung prima dengan trial division sampai 100.000, mengubah 250.000 angka menjadi teks dan menghitung panjang karakter, lalu membuat list 64 angka dan memindainya 30.000 kali. Baris cetak membuang output ke sink, tetapi formatting dan setiap pemanggilan tulis tetap dijalankan. Build source dihitung terpisah. C/Clang bukan peserta ranking bahasa; hasil native referensinya ditampilkan sendiri di bawah.Other workloads sum 1 through 10 million, compute naive recursive Fibonacci(34), count primes by trial division through 100,000, convert 250,000 numbers to text and count characters, then create a 64-number list and scan it 30,000 times. The print workload discards output, but still performs formatting and every write call. Source build time is measured separately. C/Clang is not ranked as a language entry; its native reference results are shown separately below.
| WorkloadWorkload | YAZA | C / Clang | YAZA ÷ C |
|---|---|---|---|
| Hello World · proses mulaiHello World · process start | 3.277 | 2.030 | 1.61× |
| Cetak 50.000 barisPrint 50,000 lines | 5.564 | 4.150 | 1.34× |
| Jumlahkan 10 juta integerSum 10 million integers | 6.454 | 2.679 | 2.41× |
| Fibonacci rekursif · 34Recursive Fibonacci · 34 | 17.440 | 11.741 | 1.49× |
| Hitung bilangan prima · sampai 100.000Prime count · up to 100,000 | 5.704 | 4.278 | 1.33× |
| Angka ke teks + panjangNumber to text + length | 16.313 | 8.796 | 1.85× |
| Buat + pindai listCreate + scan list | 4.306 | 2.425 | 1.78× |
| ToolchainToolchain | Waktu buildBuild time |
|---|---|
| YAZA | 446.8 |
| .NET | 679.7 |
| Java | 309.9 |
| Go | 149.5 |
| Nim | 474.2 |
| Kotlin/JVM | 2,042.9 |
| C / Clang · reference | 45.9 |
Waktu build mengikuti perintah dan cache yang tersedia saat benchmark. Ini bukan ukuran build bersih pertama; bahasa yang dijalankan sebagai source tanpa langkah compile tidak punya angka build sejenis.Build times reflect the commands and caches available during the run. They are not clean first-build timings; source runtimes without an explicit compile step have no equivalent build figure.
02 · Server HTTP02 · HTTP servers
Server lokal mengembalikan JSON dengan kontrak yang sama. Tabel ini menampilkan GET response JSON kecil, median tiga pengulangan, pada tiga tingkat concurrency.Local servers return JSON with the same response contract. This table shows the small JSON GET response, median of three repeats, at three concurrency levels.
Di concurrency 32, route health YAZA mencapai p50 103.5 ms, sementara GET JSON kecil mencapai 105.9 ms dan sekitar 401 request/detik. Pada GET JSON kecil, Go mencatat 270 µs / 93,179 request/detik dan Node.js 284 µs / 99,228 request/detik. Hasil ini menunjukkan bottleneck konkurensi yang besar pada versi server YAZA yang diuji.At concurrency 32, YAZA's health route reaches a 103.5 ms p50; the small JSON GET reaches 105.9 ms and about 401 requests/second. For that small JSON GET, Go records 270 µs / 93,179 requests/second and Node.js 284 µs / 99,228 requests/second. This run shows a substantial concurrency bottleneck in the tested YAZA server version.
Konkurensi berarti jumlah request yang berjalan bersamaan. p50 adalah waktu respons median; throughput adalah jumlah request sukses per detik. Waktu mencakup loopback dan pembacaan seluruh body. Jadi c=32 berarti hingga 32 request bersamaan dalam satu pengujian.Concurrency is the number of requests in flight at once. p50 is median response latency; throughput is successful requests per second. Timing includes loopback and reading the full response body. Thus c=32 means up to 32 concurrent requests in a run.
Geser tabel ke samping untuk melihat semua metrik.Scroll the table horizontally to see all metrics.
| BahasaLanguage | Konkurensi 1Concurrency 1 | Konkurensi 8Concurrency 8 | Konkurensi 32Concurrency 32 | |||
|---|---|---|---|---|---|---|
| p50 µs | req/s | p50 µs | req/s | p50 µs | req/s | |
| YAZA | 140 | 5,839 | 710 | 9,794 | 105,934 | 401 |
| Go | 39 | 23,758 | 104 | 69,385 | 270 | 93,179 |
| Nim | 37 | 25,202 | 99 | 71,866 | 370 | 78,966 |
| Python | 78 | 12,353 | 402 | 18,378 | 1,757 | 17,637 |
| Node.js | 34 | 28,057 | 83 | 93,227 | 284 | 99,228 |
| Ruby | 136 | 6,882 | 1,059 | 6,768 | 4,322 | 7,058 |
| PHP | 109 | 8,834 | 317 | 21,124 | 1,878 | 13,485 |
| Java | 76 | 12,127 | 157 | 48,664 | 374 | 79,621 |
| Kotlin/JVM | 71 | 12,683 | 169 | 43,061 | 364 | 80,884 |
| .NET / C# | 70 | 12,809 | 271 | 26,402 | 1,218 | 24,421 |
Response API menguji GET /healthz, GET /api/response (1, 16, atau 64 item), dan POST /api/echo. Tabel di atas hanya menampilkan workload GET JSON kecil; laporan lengkap mencakup p95/p99, endpoint lain, keep-alive vs koneksi baru, cold start, runtime, dan source setiap implementasi.The API suite tests GET /healthz, GET /api/response (1, 16, or 64 items), and POST /api/echo. The table above shows only the small JSON GET; the full report includes p95/p99, other endpoints, keep-alive versus new connections, cold start, runtimes, and every implementation's source.
| BahasaLanguage | Startup sampai siap (ms)Startup to ready (ms) |
|---|---|
| YAZA | 7.6 |
| Go | 32.6 |
| Nim | 31.2 |
| Python | 89.3 |
| Node.js | 161.6 |
| Ruby | 92.9 |
| PHP | 120.5 |
| Java | 206.6 |
| Kotlin/JVM | 114.3 |
| .NET / C# | 135.1 |
Cold start diukur satu kali per runtime dan compile/build tidak dimasukkan. Angka ini indikator awal, bukan perbandingan cold-start yang berulang atau stabil.Cold start was measured once per runtime and excludes compile/build. Treat these as initial indicators, not repeated or stable cold-start comparisons.
03 · Model memori03 · Memory model
“YAZA Arena” adalah pengelola memori internal berbasis arena pada native runtime saat ini. Program YAZA tidak menjalankan tracing Garbage Collection (GC) yang mencari objek mana yang masih dapat dijangkau. Arena mengelompokkan alokasi ke wilayah dengan batas ukuran dan waktu hidup tertentu.“YAZA Arena” is the current native runtime's internal arena-based memory manager. YAZA programs do not run a tracing garbage collector (GC) that searches for reachable objects. An arena groups allocations into regions with size limits and defined lifetimes.
512 MiB batas alokasi runtime saat ini. Data yang perlu hidup sepanjang program, seperti record CRUD yang dipertahankan, ditempatkan di wilayah ini dan dibersihkan saat program berhenti.current runtime allocation budget. Values that need to live for the program, such as retained CRUD records, go here and are reclaimed when the program exits.
64 MiB / request batas alokasi runtime per request HTTP. Parsing, nilai sementara, dan data response yang menggunakan allocator ini bisa dibersihkan sekaligus setelah request selesai.runtime allocation budget per HTTP request. Parsing, temporary values, and response data routed through this allocator can be reclaimed together after the request completes.
GC biasanya melacak objek yang masih hidup, lalu mengambil kembali objek yang tidak terjangkau. Arena tidak mencari objek yang tak terpakai; arena mengelola kelompok alokasi dan membebaskan seluruh kelompok pada batas reset atau shutdown. Runtime juga memiliki operasi internal untuk free, realloc, dan memindahkan alokasi antararena.A garbage collector typically tracks live objects and reclaims objects that are no longer reachable. An arena does not search for unused objects; it manages allocation groups and frees a whole group at reset or shutdown. The runtime also has internal operations to free, resize, and transfer allocations between arenas.
Batas wilayah memberi titik cleanup yang jelas dan dapat menghindari pekerjaan tracing GC. Sebagai gantinya, data harus ditempatkan di arena dengan lifetime yang benar: data yang perlu bertahan harus dipindahkan ke wilayah lebih panjang sebelum arena request direset.Region boundaries provide explicit cleanup points and can avoid tracing work. In return, values must be placed in an arena with the right lifetime: data that must persist has to be transferred to a longer-lived region before a request arena resets.
Untuk developer aplikasi: “YAZA Arena” saat ini adalah mekanisme internal runtime, bukan sintaks atau API alokasi yang perlu dipanggil langsung dari file .yz.For application developers: “YAZA Arena” is currently an internal runtime mechanism, not a syntax form or allocation API that you call directly from a .yz file.
Compiler belum menegakkan aturan move/borrow atau lifetime di source YAZA, dan belum ada jaminan memory-safety menyeluruh. Jika referensi internal bertahan setelah arenanya direset, allocator saja tidak membuktikan bahwa akses itu aman. Budget 512/64 MiB membatasi alokasi yang melewati allocator runtime, bukan seluruh RSS proses atau alokasi library eksternal.The compiler does not yet enforce move/borrow or lifetime rules in YAZA source, and there is no end-to-end memory-safety guarantee. If an internal reference outlives its arena reset, the allocator alone does not prove that access is safe. The 512/64 MiB budgets limit allocations routed through the runtime allocator, not total process RSS or allocations made by external libraries.
Implikasi untuk membaca benchmark: benchmark core mengukur satu workload membuat dan memindai list, tetapi tidak mengukur konsumsi memori, jeda GC, kebocoran, atau throughput allocator secara terpisah. Benchmark API mengukur keseluruhan server dan library JSON; hasilnya tidak membuktikan bahwa tidak adanya GC menyebabkan angka tertentu.Benchmark interpretation: the core suite includes one list creation-and-scan workload, but does not separately measure memory use, GC pauses, leaks, or allocator throughput. The API benchmark measures the full server and JSON libraries; it does not prove that the absence of GC caused any particular result.
Kesimpulan sementaraCurrent conclusion
Hasil CLI awal YAZA cukup kuat dibanding beberapa runtime yang diuji, tetapi Go dan Nim memimpin pada hampir semua workload core. Pada benchmark API ini, beban concurrency tinggi mengungkap keterbatasan server YAZA yang jauh lebih besar. Keduanya mengukur hal berbeda; hasil ini bukan klaim performa umum atau hasil lintas mesin.YAZA's early CLI results are strong against several tested runtimes, but Go and Nim lead in nearly every core workload. In this API benchmark, high concurrency exposes a much larger limitation in the YAZA server. These suites measure different things; these results are not a general performance claim or a cross-machine result.
