Menghindari Premature Optimization

Sampai di sini kita sudah mengumpulkan kotak alat yang lengkap: penghitung biaya, profiler, benchmark yang jujur, pemahaman cache dan layout, move semantics, arena, bahkan intrinsics SIMD. Justru karena alatnya kuat, bahaya terbesar section ini bukan ketidakmampuan mengoptimasi, melainkan mengoptimasi di tempat dan waktu yang salah. Optimasi dini menghabiskan waktu untuk bagian yang tidak panas, mengaburkan kode yang seharusnya jelas, dan — yang paling sering — tidak memberi kecepatan yang terukur sama sekali. Chapter penutup section ini membahas disiplin menahan diri itu, dengan satu studi kasus dua versi program yang hasilnya identik.

Kutipan Knuth dalam Konteks yang Sehat #

Kalimat yang paling sering dikutip dalam urusan ini datang dari Donald Knuth (1974): “premature optimization is the root of all evil” — optimasi dini adalah akar dari segala kejahatan. Kalimat itu sering dipotong sampai kedengaran seperti larangan mengoptimasi sama sekali, padahal konteksnya justru sebaliknya. Knuth, penulis The Art of Computer Programming yang kariernya dihabiskan untuk kode super cepat, menulis bahwa kita sebaiknya melupakan efisiensi kecil sekitar 97% dari waktu: optimasi menjadi masalah hanya karena dilakukan prematur — sebelum ada data bahwa tempat itu memang panas. Bacaan yang sehat: optimasi itu kerja profesional yang datanya harus dari pengukuran, bukan dari perasaan; dan 97% kode lain tugasnya hanya jelas dan benar.

Keterbacaan adalah Fitur #

Kode dibaca puluhan kali dan ditulis sekali, sehingga kejelasan adalah fitur yang tidak boleh ditukar demi penghematan yang tak terukur. Contoh favoritnya adalah penggantian std::swap dengan trik XOR yang populer di forum-forum lama:

void tukarXor(int& a, int& b) {
    a ^= b;
    b ^= a;
    a ^= b;   // berfungsi, tetapi tiga langkah yang harus dipecahkan pembaca
}

Versi XOR menghemat satu variabel lokal — dan mengubah tiga langkah sederhana menjadi teka-teki yang harus didekripsi pembacanya. Lebih buruk lagi, trik ini punya perangkap: bila kedua reference menunjuk objek yang sama (tukarXor(x, x)), ketiga XOR itu menggabungkan nilai dengan dirinya sendiri sampai menjadi nol — data hilang. std::swap(a, b) jelas tujuannya, bebas perangkap, dan oleh compiler diterjemahkan ke instruksi pertukaran register yang sama cepatnya. Pola pikirnya yang perlu dibawa pulang: sebelum menukar kode yang jelas dengan kode yang “lebih cepat”, buktikan dulu versi jelasnya benar-benar lambat.

Studi Kasus: Dua Versi, Satu Hasil Kerja #

Alur kerja yang sehat kita jalankan sungguhan: tulis versi paling jelas dulu, pasang penghitung, lalu biarkan data yang memutuskan. Versi pertama membangun laporan penjualan dengan gaya paling lugas — vector disalin utuh ke dalam fungsi, string laporan dibangun ulang di setiap iterasi:

// Versi jelas: paling mudah dibaca dan ditulis. Parameter vector disalin
// (pass by value), laporan dibangun ulang sebagai string baru di setiap
// iterasi. Hasil kerja benar; biaya alokasinya yang mahal. Counter alokasi
// memakai override operator new yang diperkenalkan pada chapter
// Mengurangi Alokasi Memori.
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <new>
#include <string>
#include <vector>

long alokasiBaru = 0;        // penghitung global pemanggilan operator new

void* operator new(std::size_t n) {
    ++alokasiBaru;
    if (void* p = std::malloc(n)) return p;
    throw std::bad_alloc{};
}

void operator delete(void* p) noexcept { std::free(p); }
void operator delete(void* p, std::size_t) noexcept { std::free(p); }

struct Pesanan {
    std::string id;
    std::string kota;
    int unit = 0;
    int hargaPerUnit = 0;
};

// Versi jelas: vector disalin utuh, string laporan baru tiap iterasi.
std::string buatLaporan(std::vector<Pesanan> pesanan) {
    std::string laporan;
    int total = 0;
    for (const Pesanan& p : pesanan) {
        laporan = laporan + p.id + ";" + p.kota + ";"
                + std::to_string(p.unit * p.hargaPerUnit) + "\n";
        total += p.unit * p.hargaPerUnit;
    }
    laporan += "grand total : " + std::to_string(total) + "\n";
    return laporan;
}

int main() {
    std::vector<Pesanan> pesanan;
    for (int i = 1; i <= 1500; ++i) {
        pesanan.push_back({"PESANAN-2024-" + std::to_string(10000 + i),
                           (i % 3 == 0 ? "Bandung" : (i % 3 == 1 ? "Jakarta" : "Surabaya")),
                           1 + i % 5, 1000 + (i % 7) * 250});
    }

    alokasiBaru = 0;
    std::string laporan = buatLaporan(pesanan);
    long a = alokasiBaru;

    std::cout << "baris pertama : "
              << laporan.substr(0, laporan.find('\n')) << '\n';
    std::cout << "jumlah baris  : "
              << std::count(laporan.begin(), laporan.end(), '\n') << '\n';
    std::cout << laporan.substr(laporan.find("grand total : "));
    std::cout << "alokasi heap  : " << a << '\n';
    return 0;
}

Output yang Dihasilkan:

baris pertama : PESANAN-2024-10001;Jakarta;2500
jumlah baris  : 1501
grand total : 7869250
alokasi heap  : 4502

Programnya benar, mudah dibaca, dan selesai dalam hitungan milidetik — untuk 1.500 pesanan, versi ini sudah cukup. Penghitung alokasi (idiom operator new dari chapter Mengurangi Alokasi Memori) pun baru kita pasang saat curiga: 4.502 alokasi terukur, berasal dari salinan vector beserta seluruh string id di dalamnya (parameternya by value), ditambah string laporan baru dan penyesuaian kapasitasnya di setiap iterasi. Angka itulah data — bukan tebakan — yang menyatakan versi ini boros bila dipanggil ribuan kali per detik. Baru setelah angka itu ada, kita tulis versi terukurnya:

// Versi terukur: hasil kerja sama persis dengan versi jelas, tetapi biaya
// alokasinya ditekan setelah data profil/penghitung menunjuk masalahnya.
// Parameter lewat const& (tanpa salinan), kapasitas disiapkan sekali lewat
// reserve, dan potongan ditambahkan ke satu buffer (operator +=).
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <new>
#include <string>
#include <vector>

long alokasiBaru = 0;        // penghitung global pemanggilan operator new

void* operator new(std::size_t n) {
    ++alokasiBaru;
    if (void* p = std::malloc(n)) return p;
    throw std::bad_alloc{};
}

void operator delete(void* p) noexcept { std::free(p); }
void operator delete(void* p, std::size_t) noexcept { std::free(p); }

struct Pesanan {
    std::string id;
    std::string kota;
    int unit = 0;
    int hargaPerUnit = 0;
};

// Versi terukur: satu buffer yang kapasitasnya cukup sejak awal.
std::string buatLaporan(const std::vector<Pesanan>& pesanan) {
    std::string laporan;
    laporan.reserve(pesanan.size() * 40 + 32);
    int total = 0;
    for (const Pesanan& p : pesanan) {
        laporan += p.id;
        laporan += ';';
        laporan += p.kota;
        laporan += ';';
        laporan += std::to_string(p.unit * p.hargaPerUnit);
        laporan += '\n';
        total += p.unit * p.hargaPerUnit;
    }
    laporan += "grand total : ";
    laporan += std::to_string(total);
    laporan += '\n';
    return laporan;
}

int main() {
    std::vector<Pesanan> pesanan;
    for (int i = 1; i <= 1500; ++i) {
        pesanan.push_back({"PESANAN-2024-" + std::to_string(10000 + i),
                           (i % 3 == 0 ? "Bandung" : (i % 3 == 1 ? "Jakarta" : "Surabaya")),
                           1 + i % 5, 1000 + (i % 7) * 250});
    }

    alokasiBaru = 0;
    std::string laporan = buatLaporan(pesanan);
    long a = alokasiBaru;

    std::cout << "baris pertama : "
              << laporan.substr(0, laporan.find('\n')) << '\n';
    std::cout << "jumlah baris  : "
              << std::count(laporan.begin(), laporan.end(), '\n') << '\n';
    std::cout << laporan.substr(laporan.find("grand total : "));
    std::cout << "alokasi heap  : " << a << '\n';
    return 0;
}

Output yang Dihasilkan:

baris pertama : PESANAN-2024-10001;Jakarta;2500
jumlah baris  : 1501
grand total : 7869250
alokasi heap  : 1

Bedah perubahan pada versi terukur:

1. const std::vector<Pesanan>&: parameter lewat referensi konstan — tidak ada salinan vector dan tidak ada salinan string id (menghemat 1.501 alokasi).
2. reserve(pesanan.size() * 40 + 32): kapasitas laporan disiapkan sekali sebelum loop, sehingga buffer tidak pernah tumbuh dan memindahkan isinya di tengah jalan.
3. laporan += potongan: setiap potongan ditambahkan ke satu buffer yang sama, menggantikan pola laporan = laporan + ... yang membangun string baru setiap iterasi.
4. return laporan;: string besar dipindahkan (move), bukan disalin — biaya keluar dari fungsi tetap nol alokasi.

Perhatikan juga apa yang tidak kita lakukan: kita tidak mengubah struktur data, tidak menyusun ulang loop, tidak menyentuh SIMD. Optimasi terkecil yang menghilangkan 99,98% alokasi sudah lebih dari cukup — menambah kompleksitas di atasnya justru kembali ke pola prematur. Dan bila fungsi ini ternyata hanya dipanggil tiga kali seumur hidup program, versi jelas pun tetap pilihan yang sah.

Checklist: Kapan Optimasi Layak Dilakukan #

Sebelum mengubah satu baris demi kecepatan, lewati daftar periksa ini — satu saja yang gagal, tunda dulu optimasinya:

1. Ada data profil yang menunjuk bagian ini sebagai jalur panas — bukan tebakan, melainkan hasil profiler atau penghitung seperti pada chapter Profiling.
2. Porsinya berarti: bagian itu menempati porsi nyata dari waktu total; mempercepat kode yang makan 1% waktu tidak akan terasa di mana-mana.
3. Ada angka dasar: benchmark sebelum-sesudah di mesin dan flag yang sama, dengan disiplin chapter Benchmarking.
4. Hasil kerja terjaga: output byte-per-byte sama seperti pada studi kasus di atas; siapkan uji penjaga sebelum menyentuh kode.
5. Keterbacaan terjaga: versi baru tetap bisa dijelaskan kepada rekan kerja tanpa dinding komentar; bila tidak, pertimbangkan biayanya juga.
6. Tercatat alasannya: satu komentar singkat tentang data yang memicu optimasi mencegah pembaca berikutnya mengembalikannya “agar jelas”.

Rekap Section dan Jalan ke Depan #

Section Performa dan Optimasi kini utuh; tiga belas chapter-nya membentuk satu alur kerja:

Ketiga belasnya bertumpu pada satu syarat yang mudah terlupakan di tengah antusiasme: program yang sedang kita percepat harus benar. Mempercepat kode yang salah hanya menghasilkan kesalahan yang datang lebih cepat, dan sebagian teknik tercepat di section ini — arena yang membatalkan objek sekaligus, akses mentah ke buffer, layout yang diatur tangan — adalah tepat tempat kesalahan memori bersembunyi bila disalahgunakan. Karena itu section berikutnya membalik arah pandang kita: Keamanan dan Undefined Behavior, tempat kita mempelajari apa yang bisa rusak di dalam program C++ dan bagaimana membuatnya tidak bisa rusak.

Rujukan resmi: operator new dan isocpp FAQ .