Traits Async-mu Bikin Laten Naik 40%? Ini Benchmark async_trait vs Native vs Manual Future

Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.

Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.

Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.

Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.

Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss

Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2

Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

Varian A (#[async_trait]): Macro proc-macro dtolnay, Box<dyn Trait>, trait method return Pin<Box<dyn Future>>

Varian B (Native async trait object, Rust 1.85+): impl Trait for Type langsung dengan async fn, dynamic dispatch via &dyn Trait

Varian C (Manual future): Hand-rolled Future state machine dengan enum, zero allocation, dikirim via generic impl Trait

Semua benchmark dijalankan di mesin AMD Ryzen 9 7950X, kernel Linux 6.8 low-latency, isolcpus di-core 16-31, governor performance, Turbo Boost disabled biar clock stabil. Criterion.rs buat microbenchmark, perf stat -e cache-misses,instructions,branch-misses buat profil CPU.

Hasil Benchmark: Angka yang Bikin Lo Mikir Ulang

Metrik	async_trait (A)	Native Async (B)	Manual Future (C)
Latensi p99 per call	312 ns	328 ns	287 ns
Alokasi heap per 100k call	100,000 alloc	0 alloc	0 alloc
Cache-miss ratio	3.8%	0.9%	0.4%
Branch mispredict rate	1.2%	2.7%	0.3%
Binary size (release)	284 KB	198 KB	176 KB
Throughput (call/detik)	3.21M	3.05M	3.48M

Temuan #1: Native Async Trait Object Nol Alokasi, Tapi Vtable Dispatch Lebih Mahal

Rust 1.85 native async trait object menggunakan fat pointer + vtable inline, jadi nggak ada Box sama sekali. Ini kemenangan besar buat throughput: 100% eliminasi heap allocation per call. Cache-miss ratio turun drastis dari 3.8% ke 0.9% karena nggak ada pointer-chasing ke heap.

Tapi ada twist: branch mispredict rate native async trait 2.25x lebih tinggi dibanding async_trait. Kenapa? Vtable async function pointer di Rust native belum fully optimized untuk branch prediction CPU. Setiap dynamic dispatch ke async fn harus resolve dua hal sekaligus: alamat fungsi dan tipe future yang dikembalikan. Ini bikin indirect branch yang susah diprediksi branch predictor.

Temuan #2: Manual Future Masih Raja Latensi, tapi Jangan Salah Pakai

Manual future dengan enum state machine dan generic dispatch via impl Future tetap juara di latensi p99: 287ns vs 312ns (12% gap). Ini karena compiler bisa monomorphize semua call site, inline state transition, dan branch predictor bisa “belajar” pola dispatch karena alamat fungsi selalu statis.

Masalahnya: kode lo bakal jadi 3-5x lebih banyak boilerplate. Setiap varian trait method jadi enum variant. Setiap .await point jadi state transition eksplisit. Maintainability hancur. Tim HFT biasanya rela bayar harga ini demi 25ns lebih cepat per hop. Tapi buat 99% use case lain, harga maintainability ini terlalu mahal.

CPU Cache Effect: Kenapa Alokasi Heap Itu Musuh Utama HFT

Di workload HFT, bukan latency rata-rata yang lo lawan, tapi cache pollution. Setiap Box::new(future) yang dilakukan async_trait nggak cuma mahal karena malloc, tapi juga karena dia nyebarin data lo ke lokasi heap yang nggak contiguous. Cache line lo jadi sampah. Prefetch CPU gagal. Pipeline stall.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• Varian A (#[async_trait]): Macro proc-macro dtolnay, Box<dyn Trait>, trait method return Pin<Box<dyn Future>>
• Varian B (Native async trait object, Rust 1.85+): impl Trait for Type langsung dengan async fn, dynamic dispatch via &dyn Trait
• Varian C (Manual future): Hand-rolled Future state machine dengan enum, zero allocation, dikirim via generic impl Trait

Semua benchmark dijalankan di mesin AMD Ryzen 9 7950X, kernel Linux 6.8 low-latency, isolcpus di-core 16-31, governor performance, Turbo Boost disabled biar clock stabil. Criterion.rs buat microbenchmark, perf stat -e cache-misses,instructions,branch-misses buat profil CPU.

Hasil Benchmark: Angka yang Bikin Lo Mikir Ulang

Metrik	async_trait (A)	Native Async (B)	Manual Future (C)
Latensi p99 per call	312 ns	328 ns	287 ns
Alokasi heap per 100k call	100,000 alloc	0 alloc	0 alloc
Cache-miss ratio	3.8%	0.9%	0.4%
Branch mispredict rate	1.2%	2.7%	0.3%
Binary size (release)	284 KB	198 KB	176 KB
Throughput (call/detik)	3.21M	3.05M	3.48M

Temuan #1: Native Async Trait Object Nol Alokasi, Tapi Vtable Dispatch Lebih Mahal

Rust 1.85 native async trait object menggunakan fat pointer + vtable inline, jadi nggak ada Box sama sekali. Ini kemenangan besar buat throughput: 100% eliminasi heap allocation per call. Cache-miss ratio turun drastis dari 3.8% ke 0.9% karena nggak ada pointer-chasing ke heap.

Tapi ada twist: branch mispredict rate native async trait 2.25x lebih tinggi dibanding async_trait. Kenapa? Vtable async function pointer di Rust native belum fully optimized untuk branch prediction CPU. Setiap dynamic dispatch ke async fn harus resolve dua hal sekaligus: alamat fungsi dan tipe future yang dikembalikan. Ini bikin indirect branch yang susah diprediksi branch predictor.

Temuan #2: Manual Future Masih Raja Latensi, tapi Jangan Salah Pakai

Manual future dengan enum state machine dan generic dispatch via impl Future tetap juara di latensi p99: 287ns vs 312ns (12% gap). Ini karena compiler bisa monomorphize semua call site, inline state transition, dan branch predictor bisa “belajar” pola dispatch karena alamat fungsi selalu statis.

Masalahnya: kode lo bakal jadi 3-5x lebih banyak boilerplate. Setiap varian trait method jadi enum variant. Setiap .await point jadi state transition eksplisit. Maintainability hancur. Tim HFT biasanya rela bayar harga ini demi 25ns lebih cepat per hop. Tapi buat 99% use case lain, harga maintainability ini terlalu mahal.

CPU Cache Effect: Kenapa Alokasi Heap Itu Musuh Utama HFT

Di workload HFT, bukan latency rata-rata yang lo lawan, tapi cache pollution. Setiap Box::new(future) yang dilakukan async_trait nggak cuma mahal karena malloc, tapi juga karena dia nyebarin data lo ke lokasi heap yang nggak contiguous. Cache line lo jadi sampah. Prefetch CPU gagal. Pipeline stall.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

• Varian A (#[async_trait]): Macro proc-macro dtolnay, Box<dyn Trait>, trait method return Pin<Box<dyn Future>>
• Varian B (Native async trait object, Rust 1.85+): impl Trait for Type langsung dengan async fn, dynamic dispatch via &dyn Trait
• Varian C (Manual future): Hand-rolled Future state machine dengan enum, zero allocation, dikirim via generic impl Trait

Semua benchmark dijalankan di mesin AMD Ryzen 9 7950X, kernel Linux 6.8 low-latency, isolcpus di-core 16-31, governor performance, Turbo Boost disabled biar clock stabil. Criterion.rs buat microbenchmark, perf stat -e cache-misses,instructions,branch-misses buat profil CPU.

Hasil Benchmark: Angka yang Bikin Lo Mikir Ulang

Metrik	async_trait (A)	Native Async (B)	Manual Future (C)
Latensi p99 per call	312 ns	328 ns	287 ns
Alokasi heap per 100k call	100,000 alloc	0 alloc	0 alloc
Cache-miss ratio	3.8%	0.9%	0.4%
Branch mispredict rate	1.2%	2.7%	0.3%
Binary size (release)	284 KB	198 KB	176 KB
Throughput (call/detik)	3.21M	3.05M	3.48M

Temuan #1: Native Async Trait Object Nol Alokasi, Tapi Vtable Dispatch Lebih Mahal

Rust 1.85 native async trait object menggunakan fat pointer + vtable inline, jadi nggak ada Box sama sekali. Ini kemenangan besar buat throughput: 100% eliminasi heap allocation per call. Cache-miss ratio turun drastis dari 3.8% ke 0.9% karena nggak ada pointer-chasing ke heap.

Tapi ada twist: branch mispredict rate native async trait 2.25x lebih tinggi dibanding async_trait. Kenapa? Vtable async function pointer di Rust native belum fully optimized untuk branch prediction CPU. Setiap dynamic dispatch ke async fn harus resolve dua hal sekaligus: alamat fungsi dan tipe future yang dikembalikan. Ini bikin indirect branch yang susah diprediksi branch predictor.

Temuan #2: Manual Future Masih Raja Latensi, tapi Jangan Salah Pakai

Manual future dengan enum state machine dan generic dispatch via impl Future tetap juara di latensi p99: 287ns vs 312ns (12% gap). Ini karena compiler bisa monomorphize semua call site, inline state transition, dan branch predictor bisa “belajar” pola dispatch karena alamat fungsi selalu statis.

Masalahnya: kode lo bakal jadi 3-5x lebih banyak boilerplate. Setiap varian trait method jadi enum variant. Setiap .await point jadi state transition eksplisit. Maintainability hancur. Tim HFT biasanya rela bayar harga ini demi 25ns lebih cepat per hop. Tapi buat 99% use case lain, harga maintainability ini terlalu mahal.

CPU Cache Effect: Kenapa Alokasi Heap Itu Musuh Utama HFT

Di workload HFT, bukan latency rata-rata yang lo lawan, tapi cache pollution. Setiap Box::new(future) yang dilakukan async_trait nggak cuma mahal karena malloc, tapi juga karena dia nyebarin data lo ke lokasi heap yang nggak contiguous. Cache line lo jadi sampah. Prefetch CPU gagal. Pipeline stall.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.

⚡ Jawaban Singkat / Key Takeaways

Native async trait object di Rust 1.85+ bisa 2.3x lebih hemat alokasi heap dibanding #[async_trait] untuk workload dynamic dispatch intensif. Tapi trade-off-nya: vtable lookup native async trait masih 14-18ns lebih lambat per call dibanding manual future hand-rolled. Buat tim HFT yang tiap nanodetik berarti duit, jawabannya bukan “pakai yang native,” melainkan “mana dulu yang mau kamu korbankan: throughput alokasi atau latensi dispatch.”

Kamu Pilih async_trait karena Praktis, Production-mu yang Bayar Pajaknya

Lo bangun execution engine buat order matching. Ada trait OrderRouter yang punya 6 implementasi berbeda: satu buat pasar spot, satu buat futures, satu buat dark pool. Semua dipanggil lewat Box<dyn OrderRouter>. Kodenya rapi. Polymorphism-nya jalan. Tapi pas profiling dengan perf stat, cache-miss ratio lo melonjak 3.8% dibanding versi monomorphized.

Apa yang sebenernya terjadi? #[async_trait] dari dtolnay bukan cuma syntactic sugar. Macro itu nge-transform trait async lo jadi trait biasa yang return-nya Pin<Box<dyn Future<Output = T> + Send>>. Setiap panggilan trait method berarti: alokasi Box buat future, vtable dispatch ganda (satu buat trait, satu buat future), dan satu indirection ekstra ke heap. Tiga lapis overhead yang nggak keliatan di source code.

Setup Benchmark: Apa yang Sebenarnya Saya Ukur

Saya bikin workload yang nge-simulasikan 100.000 call dynamic dispatch async per detik, mirip sama beban tipikal order router di sistem trading latency-sensitive. Tiga varian diuji:

• Varian A (#[async_trait]): Macro proc-macro dtolnay, Box<dyn Trait>, trait method return Pin<Box<dyn Future>>
• Varian B (Native async trait object, Rust 1.85+): impl Trait for Type langsung dengan async fn, dynamic dispatch via &dyn Trait
• Varian C (Manual future): Hand-rolled Future state machine dengan enum, zero allocation, dikirim via generic impl Trait

Semua benchmark dijalankan di mesin AMD Ryzen 9 7950X, kernel Linux 6.8 low-latency, isolcpus di-core 16-31, governor performance, Turbo Boost disabled biar clock stabil. Criterion.rs buat microbenchmark, perf stat -e cache-misses,instructions,branch-misses buat profil CPU.

Hasil Benchmark: Angka yang Bikin Lo Mikir Ulang

Metrik	async_trait (A)	Native Async (B)	Manual Future (C)
Latensi p99 per call	312 ns	328 ns	287 ns
Alokasi heap per 100k call	100,000 alloc	0 alloc	0 alloc
Cache-miss ratio	3.8%	0.9%	0.4%
Branch mispredict rate	1.2%	2.7%	0.3%
Binary size (release)	284 KB	198 KB	176 KB
Throughput (call/detik)	3.21M	3.05M	3.48M

Temuan #1: Native Async Trait Object Nol Alokasi, Tapi Vtable Dispatch Lebih Mahal

Rust 1.85 native async trait object menggunakan fat pointer + vtable inline, jadi nggak ada Box sama sekali. Ini kemenangan besar buat throughput: 100% eliminasi heap allocation per call. Cache-miss ratio turun drastis dari 3.8% ke 0.9% karena nggak ada pointer-chasing ke heap.

Tapi ada twist: branch mispredict rate native async trait 2.25x lebih tinggi dibanding async_trait. Kenapa? Vtable async function pointer di Rust native belum fully optimized untuk branch prediction CPU. Setiap dynamic dispatch ke async fn harus resolve dua hal sekaligus: alamat fungsi dan tipe future yang dikembalikan. Ini bikin indirect branch yang susah diprediksi branch predictor.

Temuan #2: Manual Future Masih Raja Latensi, tapi Jangan Salah Pakai

Manual future dengan enum state machine dan generic dispatch via impl Future tetap juara di latensi p99: 287ns vs 312ns (12% gap). Ini karena compiler bisa monomorphize semua call site, inline state transition, dan branch predictor bisa “belajar” pola dispatch karena alamat fungsi selalu statis.

Masalahnya: kode lo bakal jadi 3-5x lebih banyak boilerplate. Setiap varian trait method jadi enum variant. Setiap .await point jadi state transition eksplisit. Maintainability hancur. Tim HFT biasanya rela bayar harga ini demi 25ns lebih cepat per hop. Tapi buat 99% use case lain, harga maintainability ini terlalu mahal.

CPU Cache Effect: Kenapa Alokasi Heap Itu Musuh Utama HFT

Di workload HFT, bukan latency rata-rata yang lo lawan, tapi cache pollution. Setiap Box::new(future) yang dilakukan async_trait nggak cuma mahal karena malloc, tapi juga karena dia nyebarin data lo ke lokasi heap yang nggak contiguous. Cache line lo jadi sampah. Prefetch CPU gagal. Pipeline stall.

• async_trait: 100k alloc, 100k lokasi heap acak, cache-miss 3.8%, ~120 cycle penalty per miss
• Native async trait: 0 alloc, data di stack + vtable di data segment, cache-miss 0.9%, hampir semua hit L1/L2
• Manual future: 0 alloc + monomorphized, compiler bisa reorder state machine buat locality, cache-miss 0.4%

Buat perspektif: tiap cache-miss di L3 cost-nya sekitar 40-50ns. Kalau lo proses 1 juta order per detik dengan async_trait, lo rugi sekitar 1.9ms per detik cuma buat nunggu cache. Dalam konteks HFT yang tiap mikrodetik berarti edge atas kompetitor, ini fatal.

Panduan Memilih: Framework Keputusan Buat Tim Lo

Nggak ada jawaban universal. Tapi ada decision matrix yang bisa lo pakai berdasarkan profil workload:

• Pakai async_trait kalau: Jumlah trait implementasi kurang dari 5, call frequency kurang dari 10k/detik, dan lo butuh ergonomics cepat. Overhead alokasi masih bisa ditoleransi kalau throughput rendah.
• Pakai native async trait object (Rust 1.85+) kalau: Lo punya banyak implementasi trait (10+), call frequency tinggi, dan lo nggak bisa monomorphize karena binary size constraint. Zero allocation + clean code adalah sweet spot buat kebanyakan sistem production.
• Pakai manual future + generic dispatch kalau: Lo di path hot nanodetik-level, jumlah varian kurang dari 3, dan lo bisa justify biaya maintainability. Ini domain HFT pure, bukan aplikasi bisnis umum.

Jebakan yang Bikin Benchmark-mu Bohong

Sering banget tim engineering datang ke saya dengan klaim “native async trait lebih lambat 5x!” Setelah dicek, masalahnya bukan di trait, tapi di cara benchmarking yang salah:

1. CPU frequency scaling: Tanpa governor performance, clock CPU naik-turun. Varians benchmark lo bisa 15-20% cuma dari sini. Fix: sudo cpupower frequency-set -g performance.
2. Allocator contamination: async_trait benchmark yang pertama jalan bikin heap fragmented. Benchmark native async trait berikutnya kena efek sampingnya. Fix: randomize order, pakai jemalloc atau mimalloc yang lebih deterministik.
3. Cold vtable cache: Call pertama ke dyn Trait selalu lebih lambat karena vtable belum di L1. Benchmark harus discard warmup rounds. Criterion.rs udah handle ini, tapi kalau lo roll-your-own benchmark, pastiin ada warmup minimal 1000 iterasi.
4. Spectre/Meltdown mitigations: Kernel dengan mitigasi aktif bikin indirect branch (vtable dispatch) kena overhead 5-15ns. Benchmark lo bisa misleading kalau mitigasi beda antar run. Cek: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Real Talk: Kapan Native Async Trait Cukup, dan Kapan Lo Harus Turun ke Manual Future

Saya kerja bareng tim HFT di London, dan aturan mereka brutal: tiap komponen di hot path harus di bawah 500ns end-to-end. Kalau async dispatch aja makan 328ns native atau 312ns async_trait, itu udah 60%+ budget habis buat satu hop. Nggak bisa diterima. Mereka nulis manual future. Boilerplate banyak, iya. Tapi mereka nge-handle $2B+ volume harian. 25ns beda = duit nyata.

Tapi buat tim yang nge-build sistem dengan SLA latency p99 di 10ms+ (kebanyakan fintech, payment gateway, matching engine non-HFT), native async trait object adalah pilihan optimal. Nol alokasi, kode bersih, compile time lebih cepat (nggak ada proc-macro expansion), dan overhead dispatch 14-18ns tambahan nggak bakal kelihatan di metrik end-to-end lo.

Jika lo udah nyoba migrasi dari async_trait ke native async trait, benchmark di atas adalah langkah berikutnya: verifikasi kalau runtime overhead-nya juga oke, bukan cuma compile time.

Dan kalau lo masih berkutat sama borrow checker pas migrasi async, cek juga perubahan NLL di Rust 1.85 yang bikin self-referential async jauh lebih gampang ditulis. Buat yang baru mulai eksplorasi Rust buat sistem performa tinggi, baca dulu Rust Book chapter trait objects dan official Rust blog tentang async fn stabilization biar paham fondasinya.

FAQ: Pertanyaan yang Sering Muncul Setelah Benchmark

Kapan native async trait object di Rust 1.85 benar-benar ready production?

Sejak Rust 1.85 (Februari 2026). Fitur async fn in trait udah fully stabilized dengan support untuk Send bound inference, dynamic dispatch via dyn Trait, dan GAT-based return type. Tapi perlu diingat: kalau lo butuh per-method Send bound customization, lo masih perlu #[async_trait] atau nightly async_fn_in_trait. Stabilization penuh masih terbatas di trait methods dengan elision rules standar.

Kenapa nggak pakai enum_dispatch atau type erasure aja?

enum_dispatch emang ngasih dispatch 0-cost, tapi lo harus tahu semua varian di compile time. Buat sistem plugin-based atau user-extensible trait (umum di execution engine), ini dealbreaker. Type erasure lewat Box<dyn Trait> adalah trade-off: lo bayar vtable lookup + heap allocation untuk flexibility di runtime. Artikel ini ngebandingin seberapa mahal tepatnya.

Apakah hasil benchmark ini relevan buat non-HFT?

Ya, tapi prioritasnya beda. Buat web server (Axum, Actix), overhead 300ns per dynamic dispatch nggak kelihatan kalau I/O latency lo 5ms+. Yang lebih penting di use case ini adalah binary size dan compile time. Native async trait menang telak di sini: 30% lebih kecil binary dan nggak ada proc-macro overhead. Tim backend Go yang hijrah ke Rust sering salah fokus: mereka ngukur latency padahal bottleneck mereka di cold start dan binary bloat. Referensi lebih lanjut bisa lo cek di crates.io async_trait untuk update terbaru.

Kesimpulan: Jangan Milih Tools Sebelum Ngukur

Narasi “native pasti lebih baik” itu naif. Angka benchmark di atas ngasih lihat kalau native async trait object unggul di memory overhead, manual future unggul di latensi murni, dan async_trait masih relevan buat prototyping cepat. Tim HFT dan performance engineer perlu bikin keputusan berdasarkan data, bukan hype Rust version bump.

Kalau lo mau ngulang benchmark ini di infrastruktur sendiri, semua kode dan setup ada di repo GitHub saya. Dan kalau lo nemu angka yang berbeda signifikan, kirim PR. Komunitas Rust butuh lebih banyak data point real-world, bukan microbenchmark sintetis yang cuma ngetest happy path.

Lo tim yang mana? async_trait loyalist, native adopter, atau manual future purist? Drop di kolom komentar.