Sekilas

Dalam diskusi mengenai .NET backend, salah satu perdebatan yang sering muncul adalah: EF Core atau Dapper?

Biasanya perdebatan dimulai dari benchmark. Dapper terlihat lebih cepat, terutama pada query sederhana. Angka benchmark dapat menunjukkan perbedaan yang cukup menarik:

Dapper  : 200 µs
EF Core : 350 µs
Selisih : 150 µs

Dari sini kemudian muncul kesimpulan:

"Dapper lebih cepat, jadi EF Core lambat dan sebaiknya tidak digunakan."

Masalahnya, arsitektur software tidak seharusnya ditentukan hanya berdasarkan microbenchmark.

Pertanyaan yang lebih penting adalah:

Apakah penghematan 150 mikrodetik sebanding dengan kompleksitas dan biaya maintainability yang mungkin muncul?

Microbenchmark Tidak Sama dengan Aplikasi Nyata

Sebuah API request biasanya tidak hanya melakukan satu query database.

Alurnya dapat terlihat seperti ini:

Client
  ↓
Network
  ↓
API Gateway / Middleware
  ↓
Authentication
  ↓
Business Logic
  ↓
Database Query
  ↓
ORM
  ↓
Serialization
  ↓
Network Response

Pada aplikasi nyata, gambaran waktu dapat menjadi:

Network              1–10 ms
Middleware           1–5 ms
Database Query       5–50 ms
ORM overhead         0.15 ms

Jika EF Core menambahkan overhead 150 mikrodetik dibandingkan Dapper, maka perbedaannya sering kali relatif kecil dibandingkan total waktu request.

Bukan berarti microbenchmark tidak berguna. Benchmark tetap sangat berguna untuk memahami karakteristik sebuah teknologi. Namun, hasil benchmark perlu dimasukkan ke dalam konteks workload aplikasi yang sebenarnya.

Kapan Microsecond Menjadi Penting?

Microsecond tetap dapat menjadi masalah pada skala tertentu.

Misalnya sebuah endpoint menerima 10.000 request per detik dan EF Core memiliki overhead tambahan sebesar 200 mikrodetik per request.

10.000 request/detik
× 200 µs
= 2 CPU-second kerja tambahan setiap detik

Pada kondisi tersebut, perbedaan kecil mulai memiliki dampak nyata terhadap:

Jadi pertanyaannya bukan:

"Apakah selisihnya hanya microsecond?"

Melainkan:

Berapa kali operasi tersebut dilakukan?

Performa harus selalu dievaluasi berdasarkan frekuensi dan skala workload.

Maintainability Juga Memiliki Biaya

Benchmark biasanya mengukur waktu eksekusi. Namun software engineering memiliki biaya lain yang jauh lebih sulit dimasukkan ke dalam sebuah benchmark:

Sebagai contoh, anggap sebuah fitur dapat dibuat menggunakan EF Core dalam dua hari, tetapi implementasi manual menggunakan SQL dan Dapper membutuhkan tiga hari.

Jika terdapat 100 fitur:

EF Core productivity advantage:
100 × 1 engineer-day
= 100 engineer-days

Sementara keuntungan performa mungkin hanya:

200 µs per request

Jika aplikasi tidak memiliki traffic yang sangat tinggi, penghematan waktu engineering tersebut dapat jauh lebih bernilai daripada penghematan beberapa ratus mikrodetik.

Ini adalah alasan mengapa keputusan teknologi tidak boleh hanya menggunakan angka benchmark.

EF Core Memiliki Biaya, Tetapi Juga Memberikan Nilai

EF Core memiliki overhead karena menyediakan berbagai fitur:

Semua fitur tersebut membutuhkan biaya komputasi.

Namun fitur tersebut juga mengurangi jumlah kode dan kompleksitas yang harus ditangani developer.

Sebagai contoh:

var order = await context.Orders
    .Include(x => x.Items)
    .FirstOrDefaultAsync(x => x.Id == id);

order.Status = OrderStatus.Paid;

await context.SaveChangesAsync();

EF Core menangani banyak hal di belakang layar:

Dengan Dapper, developer mendapatkan kontrol lebih besar dan performa yang lebih ringan. Namun semakin banyak tanggung jawab yang perlu ditangani secara eksplisit.

Tidak ada pilihan yang selalu lebih baik. Ada trade-off.

EF Core Tidak Harus Selalu Digunakan dengan Tracking

Salah satu kesalahan yang sering membuat EF Core terlihat lambat adalah menggunakan change tracking untuk query yang sebenarnya hanya digunakan untuk membaca data.

Contoh:

var users = await context.Users.ToListAsync();

Jika hasilnya tidak akan dimodifikasi, lebih tepat menggunakan:

var users = await context.Users
    .AsNoTracking()
    .Select(x => new UserDto
    {
        Id = x.Id,
        Name = x.Name
    })
    .ToListAsync();

Dengan pendekatan ini:

Artinya, membandingkan Dapper dengan EF Core yang digunakan secara tidak optimal bukanlah perbandingan yang sepenuhnya adil.

Perbandingan yang lebih masuk akal adalah:

Dapper
vs
EF Core AsNoTracking + Projection
vs
EF Core Compiled Query

Pada kondisi tersebut, gap performa dapat menjadi jauh lebih kecil.

EF Core yang Digunakan Salah Bisa Menjadi Lambat

Namun, mengatakan bahwa semua masalah performa EF Core hanyalah mitos juga tidak benar.

EF Core dapat menjadi sangat lambat jika digunakan dengan pola yang salah.

Contoh masalah umum:

N+1 Query

1 query mengambil orders
+
100 query mengambil customer
=
101 query

Masalah ini jauh lebih besar daripada perbedaan 100 atau 200 mikrodetik pada microbenchmark.

Include Berlebihan

Mengambil object graph yang sangat besar hanya untuk menggunakan beberapa field dapat menyebabkan: