Ngobrolin Big-O
Ringkasan Episode
Bantu KoreksiEpisode ini membahas tentang Big O Notation, sebuah konsep fundamental dalam ilmu komputer yang digunakan untuk mengukur kompleksitas performa kode. Diskusi dimulai dengan pengalaman tim mengenai pembelajaran Big O di kampus dan relevansinya dalam coding interview. Topik utama mencakup pengenalan berbagai jenis notasi kompleksitas seperti O(1), O(n), O(log n), O(n²), hingga O(n!), serta perbedaan antara Big O (worst case scenario), Omega (best case scenario), dan Theta notation. Episode juga menampilkan studi kasus nyata dari dunia kerja, termasuk kisah menarik tentang sistem penyimpanan 15.000 kunci mobil yang menerapkan konsep indexing secara fisik, serta contoh implementasi query optimization untuk WordPress block editor.
Poin-poin Utama
- •Big O Notation adalah representasi matematis untuk mengukur kompleksitas waktu atau ruang dari suatu algoritma, dengan fokus pada worst case scenario
- •Terdapat tiga jenis notasi kompleksitas: Big O (worst case), Omega (best case), dan Theta (ketika keduanya sama)
- •Jenis-jenis kompleksitas yang dibahas: O(1) konstan, O(n) linear, O(log n) logaritmik, O(n²) kuadratik, dan O(n!) eksponensial
- •Database indexing berperan penting dalam optimasi performa query, analog dengan sistem indeks pada buku atau yellow pages
- •Studi kasus nyata: sistem penyimpanan 15.000 kunci mobil menggunakan pengelompokan berdasarkan 2 digit pertama nomor plat untuk efisiensi pencarian
- •Contoh implementasi nyata: optimasi query WordPress block editor dengan teknik batching query menjadi hanya 2 query per halaman, menghindari nested loop yang berpotensi menyebabkan O(n³) atau lebih
- •Penting untuk berhati-hati dengan ORM yang mengorbankan performa untuk developer experience, serta disarankan untuk mengecek query hasil ORM dan mengoptimalkannya dengan raw query jika diperlukan
Hai, selamat malam.
Halo-halo, sudah lama tidak bertemu, baru seminggu sih.
- Seminggu lalu. - Seminggu lalu kita gak bisa.
- Dua minggu lah jadinya. - Iya, dua minggu ya.
Dua minggu tidak bertemu, gimana kabarnya.
Gimana pengalaman IO Extended-nya, mudah-mudahan.
Buat ketemu, ngobrol-ngobrol, dan bisa bertegur sapah.
- Kita kemarin ketemu. - Yang gak ikut.
Ikut, iya.
Eh, event bukannya di satu kota gak ya? Gak sama sekali?
- Gak jadi, gak sama sekali. - Gak jadi.
Gak, gak, gak, gak kena waktunya banyak banget ininya.
Oh, yang Bali cancel, gak bisa, jadi mendadak gak bisa.
Gak bisa, karena ada urusan.
- Ada urusan. - Terus...
Minggu lalu ya, bukan minggu kemarin loh, minggu yang lalu ada acara keluarga.
Hmm, terus harus hemat-hemat juga ya, hemat-hemat...
Apa namanya, redwit waktu, karena bakal berangkat ya.
Iya, terus kalau minggu ini gak tega juga, karena deket banget kan minggu depan sudah berangkat.
- Jadi... - Berangkat kemana tuh, berangkat kemana sih ya?
Tunggu tanggal mainnya.
Iya, nanti kita live langsung, semua ada di sana.
- Live? - Sama...
- Iya, dikit-dikit gak bisa akses. - Nggak, gak live.
- Rekaman, rekaman, rekaman, semua ada di sana. - Rekaman, rekaman garam tanda, enggak.
Rekaman sama Pak Sandika Gali, mudah-mudahan Pak Sandika Gali mau ya.
Iya, mudah-mudahan.
- Oke, oke. - Sama Jessica.
- Jessica, oh iya, berlima ya. - Yes, Power Rangers compete semua ya.
Sekarang kita Power Rangers, udah bukan mingguan lagi.
Lihat transkrip lengkap (2044 segmen lagi)
Iya, bukan mingguan lagi.
Power Rangers ya, yang penyanyi berlima gak ada ya, grup bandnya.
Kan itu five quake quake.
Apa itu?
Entah, ada gak sih?
Ada, Blackpink kan lima, Blackpink lima gak sih?
- Iya. - Kewen semua tapi...
- Tapi Power Rangers. - Paling benar sih.
Informasi paling benar Power Rangers sih, Power Rangers kan kewennya dua tuh.
- Power Rangers kan betul. - Benar sih.
Kewen kan melenceng, tadinya kan dari grup musik.
Jadi ngomongin kemana-mana nih.
Oke, belum kemana-mana, seperti biasa, bertemu lagi dengan kita bertiga.
Ada saya Riza, ada Ika, dan ada Irfan.
Di setelah malam, kakak setelah malam waktunya.
- Nah, berapa jam? - Nah, berapa jam?
Kirain sudah lupa.
Oke, malam ini kan kita, seperti di judul ya.
Kita mau bahas tentang performa. Performa maksud performa gak?
Fundamental ya, fundamental.
Fundamental tapi terkait performa.
Performa bukan performa aplikasi, tapi lebih ke kode.
Nipet ya, potongan kode.
Gak semua, kalau semua aplikasi bisa juga.
Tapi kayaknya terlalu banyak ya.
Jadi biasanya yang di-check itu, yang di-evaluasi itu adalah barisan kode.
Misalkan ada perulangan.
- Kondisional. - Kondisional.
Ya, apapun yang pure function sih ya.
- Apapun yang function, bukan pure. - Unit ya, function ya.
Unit S gitu ya.
Nah, istilahnya itu adalah Biko.
Biko itu cuma notation, mewakili ya.
Jadi dia gak ada arti apa-apa sebenarnya.
Cuma mewakili bahwa kompleksitasnya sejauh mana.
Ya, kayak simul matematis sih ya.
Maksudnya itu gak ada kepanjangannya O gitu atau apa ya.
O aja kayak X. X itu kan mencerminkan nilai yang harus dicari gitu.
X adalah blablabla.
O ini kan adalah representasi dari time atau space kompleksiti.
Nah, nanti detailnya dibahas lebih dalam lagi kali ya.
Yes.
Teman-teman di sini sudah pernah tahu gak tentang Biko notation?
Sudah pernah pajari belum?
Ada yang sudah pernah interview, coding interview gak?
Muncul gak sih di coding interview kayak gini?
Biasanya dikasih warisan kode, terus tahu kode yang kita tuliskan sendiri.
Terus coba ini Biko-nya apa biasanya gitu ya.
Dan yang paling kompleks apa coba?
Pas interview untungnya gak ditanya sih.
Karena waktu interview dulu belum tahu.
Ini taunya kayak ya relatif baru lah.
Udah ternyata kerja dan udah ternyata mid-level baru belajar sendiri ini.
Oke, lagi pertanyaan buat.
Wah, Nur Holid ya.
Nur Holid ini yang kemarin kita ketemu di Depok.
Sekarang pertanyaan buat anak kuliah.
Hah, foto?
Foto-foto aja.
Foto dong.
Foto kan?
Foto, ya.
Foto.
Kayak anak Jelis itu foto.
Pertanyaan buat anak kuliah.
Biko dipelajari gak di kampus?
Ivan?
Lupa saya.
Kayaknya ada.
Di struktur data.
Algoritma?
Enggak, struktur data.
Struktur data apa algoritma ya?
Alpro ya?
Atau malah justru di database?
Waktu itu.
Karena, ya.
Kalau gak salah ya di database.
Dosen yang ngajarin DB, MS.
Ngajarin tentang Big O Notation.
Salah satu sesi kuliahnya.
Karena itu kan.
Karena kompleksitas query juga bisa dihitung dengan Big O kan.
Misalnya join.
Terus kemudian inner query.
Sub-query, sorry.
Sub-query.
Ya, pull join.
Itu ada Big O Notation juga, hitungannya.
Wah, Nur Holid gak dapat.
Dari semester 1 sampai semester 13.
Banyak banget.
Jangan terus.
Pasti ajarin.
Nah, cuma kalau misalnya ikut Mata Kuliah CS50 dari Harvard.
Yang open source.
Ada tuh Mata Kuliah Basic Computer Science.
Yang memang dibuka untuk publik.
Yang di sana kuliah ya bayar.
Tapi di publish online.
Memang secara terbuka.
Kita boleh ngikutin.
Ada tugasnya, ada exercise dan lain-lain.
Itu di pelajaran sih.
Itu di kelas ke-3 tuh.
Coba lihat, buka aja link-nya di private chat.
Oke.
Ini sesuatu yang cukup menarik.
Eh, salah kan?
Oh, screen-nya mana?
Kok gak ada screen-nya?
Oh, pernah dikasih soal interview.
Oke, apakah screen tersebut paling drom?
Tapi pakai Big O ya.
Ditanya, ini tuh Big O-nya apa ya?
Sudah kelihatan ya layarnya.
B, in-ear search.
Turun lagi, turun lagi.
Binary.
Ini ya running time ya.
Berapa lama ya?
Nah, ini ya.
Nah, ini dia.
Zoom in.
Oh, kurang.
Udah?
Berarti kayaknya Eka ini harusnya text-nya di gedein, komputernya.
Di layar baru ya?
Kan ada settingan text size kan, text size komputernya.
Gak, ini kan ngomong-ngomong dulu.
Ini kan video.
Gimana mau di zoom?
Oh, iya-iya. Gak bisa ya.
Gak bisa.
Eka lihatnya bukan di browser.
Nah, ini juga salah satu yang biasa ditanyakan ya.
Jadi, pertama kita bikin kodenya dulu.
Ditanya kan tadi apa? String ya? String itu palindrom atau bukan.
Harusnya biorangnya bisa lah ya.
Tapi abis itu ditanya, seberapa kompleksitas kode yang kita buat.
Itu salah satu tips, interview juga ya.
Selalu melakukan seperti itu.
Nah, ini cukup menarik.
Cukup menarik karena waktu pertama kali bikin hektifat di 2016 itu.
Waktu diskusi materi.
Salah satu materi yang muncul sebenarnya Bikko.
Dan rekan-rekan saya yang kebetulan kuliahnya di luar itu mereka kaget.
Karena saya dan beberapa teman-teman yang kuliah di Indonesia.
Itu ngaku tidak pernah belajar Bikko, tidak dapat di kampus, itu mereka kaget.
Karena itu salah satu yang kundang mental yang diajarin di awal-awal.
"Kok gak dapet?" "Ya" gitu.
"Maksudnya sih gak dapet?" "Anda gak percaya?" gitu.
Yang nanya, bahannya siapa tuh?
Haris-haris.
Bukan lah.
Waktu pertama kali ketemu orang penting, waktu datang ke Jakarta.
Ingat gak siapa itu namanya?
Ya.
Oh, Haris-haris sih.
Ini Alex Russell.
Ya, Alex Russell.
Itu jauh.
Oh, jauh.
Oh, 2016.
Kira-kira ingin Alex Russell.
Gak, kalau foundernya hektifat kan kuliahnya di luar.
Oke.
Ya, dan ada beberapa, ada CTO-nya Rebel Work waktu itu.
Dia juga kuliahnya di luar.
Itu kaget.
Gak.
Akhirnya ditambahin lah materi itu di kampus.
Ya, di kampus.
Tapi itu di komen udah banyak yang jawab.
Diajarin ya, berarti untung lah.
Kodekulung pendidikan kita udah dipatch.
Sudah update.
Sudah dapet, tapi mungkin tidak terlalu ditekankan.
Atau mungkin jangan inisiatif dosennya tuh.
Kayak, maksud saya, belum secara resmi ada di curriculum.
Cuma, maksud saya, dalam topik yang relevan, kayak dosennya nyelupin aja biar mahasiswanya tahu.
Ya.
Berarti dosenku bagus dong ya.
Tapi di database malah.
Bukan di ajaran basicnya.
Jadi dia ngajarnya database.
Ya mungkin dia gak ada mata kuliah dasar-dasar computer science.
Ya, jadi intinya apa?
Intinya adalah, oh itu adalah worst case scenario dari potongan kode.
Jadi kalau misalkan kode kita ada four loop di dalam four loop.
Itu dihitung kira-kira kalau datanya 100 ribu.
Misalkan gak 100 ribu dulu ya.
Kan, datanya 3 berapa?
Kalau datanya cuma 2, bentar.
Kalau datanya cuma 2 berarti dia 4 ya?
Ya, 2 kali four loop.
2 dikali 2 kan.
2 pangkat 2 ya.
2 pangkat 2.
Karena 4 di dalam 4 kan.
Kalau 3 berarti 3 pangkat 2.
Karena four loopnya 2.
Gitu.
Oh bentar.
Kalau yang OO, itu kayaknya logaritma kan.
Iya.
Itu logaritma apa?
Mana dia?
Kita baca aja sama-sama.
Kalau yang pangkat itu tengah-tengah.
Ya intinya adalah worst case scenario.
Kira-kira scenario terburuk dari kode kita itu seperti apa.
Makanya muncul istilah O.
Kemudian ada representasi dari kompleksitas kode kita.
Ini harus di-share.
Jadi misalkan linear search, gimana linear search?
Linear search itu takes on order of n steps in the worst case.
This is noted with O(n).
Jadi worst case di sini maksudnya misalkan linear search.
Linear search itu kan cari dari awal sampai akhir.
Worst case itu maksudnya adalah
kalau ternyata angka atau text yang kita cari itu ujung di paling akhir.
Berarti kan dia akan menjalani semua kan.
Nah itu nasional bagai worst case scenario.
Jadi kalau linear search itu berarti apa nih bacanya?
Gimana ya bacanya?
O(n) aja ya.
O(n) ya.
Kalau binary search, binary search itu gimana?
Jadi dibagi dua ini contohnya ada angka 1-10 dibikin 3.
Sorry ada array 1-10.
Terus diambil yang tengah.
Diambil yang tengah itu angka kita lebih tinggi atau lebih besar dari angka yang mau kita cari.
Yang angka di tengah itu.
Kalau misalnya lebih besar, yang lebih kecil semua dibuang.
Terus di-repeat lagi, dibagi dua lagi.
Angka yang kita inginkan itu di sebelah kanan atau sebelah kiri dibuang, dibuang, dibuang.
Jadi makanya log n.
Log n itu kan urutan ya.
Jadi makin dari paling besar sampai paling kecil urutan.
Jadi kalau misalnya kita nyari tadi ada 10 angkanya.
Angkanya 10 item berarti 0 all log 10.
Itulah jumlah worst case nya.
Tapi mungkin sebelum ngomongin Bitgo itu sebenarnya kompleksitas kode itu bisa dinilai dari dua hal kan.
Yang pertama adalah kompleksitas ruang.
Ruang space.
Dan kedua adalah kompleksitas waktu.
Time complexity.
Seberapa lama kode itu berhasil di eksekusi.
Atau seberapa banyak membuangkan memori atau hard disk.
Jadi ada dua sebenarnya.
Nah, Bitgo ini termasuk yang time complexity.
Kalau nggak salah.
Benar nggak?
Tapi sebenarnya kayaknya Big O juga bisa deh.
Dipakai buat ngukur space complexity.
Tapi kan lebih jarang ya.
Yang sampai makan tempatnya.
Makan memori nya se ekstrim itu.
Perbedaannya kan jarang ya.
Kalau misalkan space complexity itu misalkan kita disuruh.
Misalkan ada tugas untuk membaca file.
File nya berukuran sangat besar.
Gimana strategi kita untuk membaca apakah membaca keseluruhan taro di memori.
Atau membaca baris per baris.
Yang mana yang lebih efisien secara pace.
Yang jelas yang pasti baris per baris dong.
Tapi secara kecepatan ya.
Mungkin aja bisa lebih cepat yang dibaca semua.
Karena sudah masuk ke memori dan bisa diproses.
Kembali lagi itu tergantung kebutuhan juga.
Oke tadi kita sudah bahas tentang O(n) dan O log(n) ya.
Jadi kalau linear itu cari angkanya dari kiri ke kanan atau per satu itu O(n).
Kalau binary itu dibagi dua.
Di tengah-tengah, di tengah-tengah, di tengah-tengah seperti di hadapan.
Selanjutnya ada omega.
Omega ini adalah base case scenario.
Kalau tadi bico itu worst case nya paling lama.
Kalau omega berarti base case scenario linear yang paling cepat.
Kenapa? Karena kalau angkanya yang dikari adalah yang paling kiri.
Ya dia langsung ngepet kan.
Jadi omega satu. Karena akan selalu satu kan base case scenario nya.
Jadi kadang-kadang di coding interview itu tanya worst case scenario nya gimana,
base case scenario nya gimana.
Terserah, teman-teman bisa jawab dengan istilah bico atau omega atau apa.
Atau dengan kata-kata yang sendiri gitu.
Maka pakai notasi-notasi dibilang nggak masalah sebenarnya.
Biasa kita bisa kasih contohnya kan.
Kalau pertanyaannya suruh base case sama worst case, ya berarti harus jelasin dulu.
Ya, definisinya dulu worst case scenario itu maksudnya adalah ketika misalkan tadi
pencarian string itu atau pencarian angka itu diunjung.
Yang paling tidak optimize, yang paling unlucky lah ya, paling wujung nyaringnya.
Atau kalau yang base scenario itu yang paling awal, yang gampang gitu ya.
Kalau binary tetap omega satu ya.
Kalau seandainya...
Ya begitu di dapet langsung ternyata.
Di dapet ya, pencuk saya dibalikin.
Di ternyata langsung dapet.
Ini apa?
Ada lagi, baru tahu.
Ada theta notation.
Theta ya?
Theta, ada yang kasih tahu.
Saat ketika suatu algoritma punya big O notation yang sama seperti omega.
Oh, theta.
Jadi ini kondisi khusus ya.
Jadi emang cuma, oh cuma bisa satu cara itu.
Jadi mau best, mau worst, itu cuma.
Sama.
Itu sama.
Misalnya array length ya berarti.
Nah ini contohnya.
Linear search ya.
Kalau kita punya deretan angka ini,
kalau base case scenario-nya adalah angka yang kita cari itu 20.
Langsung dapet.
Tapi kalau worst case, angka yang kita cari 50.
Sehingga kalau linear search,
dia akan cari for loop ya.
Ini sama enggak sama 50.
Nggak sama, nggak sama, nggak sama, nggak sama.
Berarti berapa kali itu? 1, 2, 3, 4, 5, 6, 7 ya.
Setelah 7 baru...
7.
Ya.
Nah ini adalah contohnya.
Jadi dia menggunakan for loopnya 1.
1 for loop.
Dan ada kondisi untuk cek angkanya sama atau tidak.
Btw mirip java strip ya.
Maksudnya buat orang yang belum pernah pakai sama sekali,
ini kayaknya familiar banget.
Bahkan loop syntax buat ngeloop-nya pun sama.
Sama.
Masih satu family, satu family.
Ini apa?
Linear search and array of string.
Oh ini kalau pencarian string ya?
Sama ya, kurang lebih sama ya.
Interestnya yang bedanya adalah
ya di datanya aja stringnya ya.
Cuman untuk carinya kan berdasarkan index kan ya.
Semakin besar indexnya.
Tetap harus di cek satu persatu,
kegitu ketemu, baru dibalikin.
Oke.
If you make two array,
to store two features of separate index,
and put the values in the same order,
so that of the first entity are stored
in the same order.
Apa ini?
Oh, implementationnya bisa beda-beda ya.
Kalau ini,
ini kayaknya mau nyimpan nama sama
nomor telepon ya.
Yang biasanya langsung simpan key value ya.
Jadi,
kalau si Carter itu nomor teleponnya ini,
si David itu nomor teleponnya ini.
Itu loopnya dua tingkat,
jadinya nested kan.
Ini enggak, ini satu.
Iya, satu, enggak ada loop.
Oh, cuma satu deh.
Oh ya, if you want.
Tapi kalau misalkan kita mau for loopnya
dua kali ya, berarti tidak optimal kan.
Ini yang di loop cuma namanya doang ya?
Bukan nomornya.
Bukan nomornya.
Jadi dia mencari berdasarkan nama.
Nah, ini udah bukan tentang Big O lagi nih.
Itu deh, kita buka yang di private chat.
Tanya Jem'nai dong.
Tanya Jem'nai buat
ngasih contoh-contoh
Big O notation yang
common.
Zoom in.
Eh, salah.
Zoom in videonya.
Nah, ini enak sih.
Menanfaatnya tanya ke LLM Chatbot.
Ini kalau yang OO1
ini optimal banget lah.
Konstan ya, konstan.
Mau kita cari seribu,
sepuluh ribu, sejuta ya sama
hasilnya. Seribu kali ya seribu kali.
Nah, itu contohnya kalau kita
udah punya indexnya.
Misalnya kita udah punya indexnya.
Nah, jelannya cuma sekali.
Jadi misalnya array kita udah tahu
item yang kita cari di index ketiga
atau ke seratus atau pertama.
Ya kerjanya kan sama.
Tentunya adalah mengakses
array berdasarkan
angka index ya.
Gak perlu cek satu-satu lagi
karena kita udah punya indexnya.
Yang kedua, linear time.
Linear time itu berarti naik begini ya.
Linear naik ya.
Sumbu X sama sumbu Y
jadi di tengah-tengah gitu ya.
Jadi menyesuaikan dengan
jumlah items.
Misalkan item yang satu
ya OO1. Kalau item yang dua
berarti OO2 atau OON.
Jumlah number itemsnya.
Kalau OO1,
kalau seribu berarti OO1.
Nah, contohnya itu
finding the maximum value
in unsorted array.
Kita punya array yang
isinya angka acak.
Kita nggak tahu tingginya
nggak diurut sama sekali.
Berarti kan tetap harus
dari awal sampai akhir cek
semua satu-satu angkanya kan.
Cek kalau lebih tinggi
distort the memory.
Cek selanjutnya
kalau nggak lebih tinggi ya udah nggak usah
ngapa-ngapain next. Cek lagi.
Harus sampai kelar kan.
Jadi kalau misalnya itemnya
array itu isinya cuma
satu angka
ya jalannya cuma sekali.
Kalau array-nya isinya lima angka, jalan lima kali.
Kalau array-nya isi
seribu angka ya seribu kali.
Ya, step-nya.
Ya, itu linear.
Kemudian yang
berdua. Nah, ini bukan pula
aneh-aneh nih.
Buat yang aneh ini matematik, udah mulai gitu-gitu
ini. Angka dua ya.
N angka dua ya.
Jadi misalkan
kalau datanya
cuma satu.
Ya, satu.
Ya, kalau datanya dua,
dua pangkat dua,
cari empat.
Kalau datanya lima, lima pangkat dua,
lima kvadrat, dua lima.
Seribu, si juta, mampu.
Ini yang forwardnya dua ya.
Nasty loop iterating
over the same array.
Jadi array-nya satu, tapi ada
loop yang sama gitu.
Misalnya apa compare kali ya?
Jadi
satu data,
ya compare tapi yang nggak optimal gitu.
Jadi misalnya kita punya data user.
Ada banyak. Nah, terus kita
ngeloop usernya.
Tapi misalnya kita mau nyari
user yang dari organisasi
yang sama atau dari sekolah yang sama.
Kita loop masing-masing user
di user pertama.
Kita loop lagi semua user di dalamnya.
Jadi loop di dalam loop buat ngecek
organisasinya sama atau nggak.
Ya.
Pokoknya, kalau ada nested loop,
nah itu yang
jadi rat-tack ya
dalam tanda kutip ya.
Sebisa mungkin
kalau bisa, jangan.
Apalagi
yang kombinasi.
Tau nggak kombinasi, pernah melakukan nggak?
Saya sih pernah dulu ya.
Gimana-gimana contohnya?
Jadi misalkan
di database
kita udah dapet nih datanya.
Abis itu kita loop lagi
di aplikasi
untuk misalkan ngambil nama
gitu kan. Kita udah select
gintang from people
misalkan atau from user di atas gitu kan.
Terus di bawah kita ngambil
data user yang lain. Terus kita mau
mapping nih, nama sama data yang lain.
Itu dikerjakan
tidak di sisi database
tapi di sisi
kode. Kita loop lagi.
Jadi itu udah berapa kali ya.
Mungkin tidak nested.
Tapi sudah ada 3 for loop.
Nah itu nanti akan ada di bawah
yang di bawah ini.
Kalau ini berarti nested ya.
Nestednya berarti 2 kan.
Nested 2 kan.
Kalau nested 3, berarti pangkat 3.
Pangkat 3 betul.
Gross Quadratically
Scroll atas?
Oh atas ini?
Iya, ini kan.
Log N ini?
Gross Logarata
Minerals Search yang tadi.
Ini contohnya gimana sih?
Nggak inget.
Saya punya
artikel sih.
Ini kan tadi
kita omongin ya.
Kalau O1 itu
ya garis lurus lah ya.
Kalau N itu dia...
Kalau yang tadi nggak dikasih contoh yang pangkat 3 ya.
Maksudnya kita mikir sendiri lah.
Concrete-nya pasti nambah berat lagi.
Makin banyak datanya
makin sama, tapi
dia waktu datanya sedikit
cepat banget, eksponen.
Log N itu naik.
Makin eksponen, tapi makin banyak datanya
ya sama aja gitu.
Makin sedikit.
Ini berarti bahaya ya, kalau orang nggak
mau saya ada manfaat
concretenya kenapa anak yang
belajar Computer Science
perlu belajar
Big O. Kan ini kalau nggak ngerti
cuma ngetes pakai data yang
dikit, wah pakai ini aja, kenceng.
Tiba-tiba jubul.
Biasanya kan kita gitu
developer juga suka gitu kan.
Di saya cepet kok orang datanya data
Dami cuma 10, ini cepet.
Kalau pasti pakai berapa datanya?
Dan sekarang lebih bahaya lagi ya.
Maksudnya jaman server loss atau cloud
ini kalau misalnya kesalahan
yang terjadi di server
billing, kalau misalnya
on-prem kan yaudah paling jubul
servernya mati yaudah.
Kalau ini lebih horror lagi.
Iya, nggak mati.
Transaksi aman.
Billingnya juga auto
scale-nya kebetulan nyala
nyalain service apa.
Nah, jumlah
jumlah 000-nya juga
terreflektir
di billing.
Iya, itu kayak kita
nggak didos diri sendiri.
Ya, nah di sini
di artikel ini ada
contoh, contohnya adalah
kalau kita punya travel app
gitu kan, jadi misalkan
kita mau filter by price.
Nah, sebenarnya kan kalau misalkan kita mau
cari filter gini kan
kita cek dulu harga minimumnya berapa
harga maksimumnya berapa.
Semakin banyak data pasti semakin
semakin lama, karena kan harus
cek satu persatu.
Jadi kalau misalkan kita punya
datanya kayak gini, ini simple aja ya
contoh dari sini
disederhanakan gitu kan.
Kita punya data ini, entah itu datanya
dari SNK,
API, atau dari database
yang terserah gitu kan.
Kita bisa lakukan dengan cara ya tadi
yang eksponensial, N2.
Iya kan?
Kalau for loopnya 2.
Jadi kita cek
yang minimum berapa
sama yang maksimum berapa.
Kalau tadi udah dibahas juga
kalau 3 di pangkat 2,
5 di pangkat 2, 10 di pangkat 2,
100 di pangkat 2. Dari 10
ke 100 itu jauh sekali bedanya.
Kalau dari 3 ke 5
mungkin masih ok lah gitu ya.
5 ke 10 juga masih ok gitu kan.
Tapi kalau udah ke 100,
1000 dan seterusnya itu jauh sekali.
Pokoknya dia
n pangkat 2.
Terus pengulangan dari
apa? Pengulangan tapi di dalamnya
ada 2 operasi.
Kalau ini kan pengulangan
dalam pengulangan. Kalau ini
pengulangan satu, tapi ada
2 operasi, dari harga paling kecil
sama dari harga paling besar.
Itu berarti
ON ya? ON, linear
time itu ya berarti kan?
Nggak ngaruh ya.
Berarti nggak ngaruh sama satu, dua.
Ya sesuai.
Linear, sesuai. Itemnya 5
ya dia jalan 5 kali yang tadi itu.
Kalau itemnya 100, dia jalan
100 kali.
Ini jauh lebih baik daripada kita bikin
4 lagi, satu lagi dibawah gitu kan.
Jauh lebih baik dibanding
yang tadi itu yang atas, yang kudrat
yang pangkat 2.
Itu adalah
ON.
Kalau O1 ya kita bisa langsung
dapat, ini
misalkan kita si datanya
itu udah kita sort duluan.
Kita bisa tahu harga yang minimum itu
pasti inggis 0.
Tapi
operasi nge-sortnya
itu nggak
pertanyaannya?
Ya maksudnya beda kan.
Mungkin hanya satu spesifik functionnya kan.
Kalau operasi sortnya kan
ada lagi nanti potongannya.
Nah sekarang jadi pertanyaan
kalau misalkan
di database kita pake sort
by price, ascending
atau descending lah.
Itu termasuk ke perhitungan
atau nggak? Masuk kan ya.
Ya makanya
kita pelajarnya, makanya
saya waktu itu pelajarinya di
di mata kuliah DB.
Tapi akan jauh
lebih buruk kalau misalkan di database
kita nggak sort, kita sortingnya
di model.
Kalau menurut saya sih
lebih bagus sortnya di database.
Iya, udah lebih optimiskan.
Karena database
punya
index.
Lebih cepat dia
sortnya. Maybe
depends ya tergantung
kehandalan
DB
database kayaknya udah
dioptimasi untuk hal-hal
seperti itu kan.
Harusnya ya built in kecuali
beneran kita bikin.
Tapi pagination di database itu
tetap masih masalah kok sampai sekarang.
Iya, iya, iya.
Itu gambarannya kira-kira
jadi gambarannya segini.
Jadi yang tadi ya
yang paling bagus ya
pasti oh satu atau lock
N itu masih oke.
Oh N ini
lampu kuning gitu ya
kalau udah N2 atau
kalau udah berpangkat-pangkat itu yang
reflekt
kata anak sekarang ya.
Iya.
Ini nama istilahnya
aja konstan logarithnya
linear quadratic exponential itu
N pangkat N ya.
Indari yang
X N pangkat N.
Ini ya. Pokoknya semua yang
berpangkat-pangkat tuh kayaknya
udah. Ini kalau udah nggak
jadi ini masih oke.
Kalau ini udah harus
di de-factor ya.
Oke.
Tapi kan maksudnya ya tergantung
harus ngapain. Tapi kan sebenarnya bisa
diakalin di
kalau untuk compare atau cari match
kan ya udah jalan dulu
sekali, di filter misalnya
filter atau find, store di
memory, baru jalan sekali lagi
buat ngak compare. Ya, kalau
use case-nya se-simple itu kan
masih bisa diakalin ya, kecuali
emang rumit banget.
Yes.
Nah, ini ada contoh-contoh
notasi
notasi Big O
yang dari
built-in
function.
Misalkan push, pop,
kemudian
unshift, dan lain-lain ya
udah banyak. Cara menghitungnya gimana?
Cara menghitungnya gini aja.
Kasih tau per baris gitu.
Jadi misalkan kalau for yang
pertama itu O N. For
yang kedua O N. Kalau ini kan O
1 ya. Kalau ini sebenernya bisa
di-ignore sih. Jadi ini
berarti N-nya ada 2. N
dikali N jadi N panggap 2.
Kalau ini berarti O 2 ya.
Coba kalau
di ini, apa namanya?
Dipasukin ke
jemana dia bisa jawab gak sih?
Apa? Coba aja yang masukin.
Big O
Big O
Big O
ya. Big O
Calculator
Your Big O Calculator
Notation Calculator. Count this
Hilangin dulu itu nya
comment-comment
O N O N nya. Bisa gak ya?
Bentar-bentar. Bentar ya.
Kita buka
bentar.
Atau CGPT.
Kita buka
2mini.
Close. Kan bisa
jemana yang di ini.
Di browser aja.
Iya ini di browser.
Tadi kan itu browsernya
Incognito.
Maksudnya jemana
Nano yang dibuild
di browser.
Nano gak bisa ditanya susah-susah.
Nanti dia
nanti dia halu.
Jadi ini coffee.
Apa? Gimana?
Prom-nya. You are
a Big O
Big O Notation
Calculator.
Close.
Calculate the
third time
complexity
of this function.
Of this
code
snippet below.
Gini.
Yang ininya dihapus.
Ini kekecilan ya.
Gak kelihatan ya.
And explain.
And explain your
chain. And explain it.
In detail.
Pake triple ini gak?
Eh udah ke pencet. Yaudahlah.
Yaudahlah.
The outer loop iterates ten times.
Karena sepuluh ya. Oh ditara sepuluh ya.
Pake N ya.
Betul.
For each iteration of the outer
loop, inner loop iterates ten times.
Inside inner loop to constant
time operation, analyzing the
complexity.
Outer loop
complexity satu
constant.
Oh inner loop juga constant.
Tapi inner loop
is nested within the outer loop.
Total number iteration is sepuluh kali sepuluh.
Sepuluh ten.
Ten times ten.
The operations
inside the inner loop.
Istilahnya namanya constant time ya.
Constant time.
Combining the complexity.
The time complexity
entire code is the product
of time complexities of outer
loop and the inner loop.
Yang O1 itu
tadi yang dimana ya?
Outer loop?
Yang outernya dianggap satu.
Oh iya. Dikali yang
nested. Jadi seratus ya.
Oh seratus gitu ya.
Constant factor
is Rignore.
Jadi kalau yang O1 itu bisa diignore.
Relationship between number of
iterations mulang berapa kali
dan input size.
Input size the number of
iteration bertambah
secara kvadrat.
Berarti O on
N pangkat dua.
Benar.
N represents benar.
Ya benar.
Size of the loop counters.
Betul sekali.
Betul. Enak ya.
Sekarang bisa tanya ke
chatbot.
Nah kalau contoh yang
apa? Ada juga nih.
Ada demo-nya. Cuma kita nggak bisa masukin
function kita sendiri.
Cuma bisa pakai contohnya
dari si
timernya.
Si calculator-nya.
Gimana caranya?
N sama dengan 10?
Plug.
Coba
yang besar lah 100.
Ini 100. Berarti
O1?
Ya.
O1. Betul.
O1 ya. Kalau ini
sama.
O1 juga.
Oh nggak. Ini area.
Ini area.
Kok nggak ada garisnya ya?
Iya. Kok nggak ada garisnya?
Ini ada 2 loop.
Berarti O2.
ON ya.
ON ya.
Linear juga.
Linear tapi
lebih besar. Betul. Beda.
Oh beda ya.
Oh.
ON kali 2.
ON kali 2.
Oh ya benar. ON kali 2.
Tapi itu 1,1.
Iya 1,1.
1,1 milion?
Iya.
Mikro itu.
Sekan. Sekan.
Time complexity ya
berarti ya.
Berarti itu tadi
N kali 2. Nah kalau ini
baru N
pangkat 2 ya.
Baru ini eksponensial.
No. Jauh sekali.
Tapi nggak di garis ya.
Iya.
Jauh banget ini.
Ini nggak ada garisnya
cuma ngasih tau ini doang.
Cuma ngasih plot doang.
Untuk ngebandingin masing-masing function
itu tadi yang biru. Yang biru
udah nggak kelihatan gitu saking.
Abu-abu puncul
merah.
Yang ini aja terlalu jauh.
Number of half.
Ini
yang dibagi 2 ya.
Iya.
Ini kayak log N.
Log N di bawah ya.
Iya.
Total number of half itu
berarti N ya.
Iya.
Log albinaries
ini
N juga.
Oh ini yang lama nih.
Iya.
Sampai hang gitu.
Kok bisa lama?
Oh ini sebenernya
2 kali ya Pak?
Ada path start? Nggak ya?
Kan ada loopnya
eh nggak deh.
Ada repeat N itu.
Oh iya.
Ini di kali last numbernya
di repeat kan.
Di repeat sebanyak
N itu.
100.
Ya 100 iya.
Satunya ada 100.
Terus abis itu di while loop
countnya
012
jadi string.
Terus sama nggak
dengan angka 1
yang jumlahnya 100 digit.
Kebanyakan ini.
Iya kan?
Ini baru
ON pangkat N
berarti ya.
Iya.
Sama ya?
Nggak, susah-susah.
Hang lagi.
Hang.
Biarin aja.
Masih lagi
calculating.
Calculating.
Oh udah berhenti.
Jadi dimana dia?
Ini...
Hah?
Kok nggak ada?
Ini gua serem deh soalnya
ini brosernya sama.
Brosernya sama.
Nanti tiba-tiba
stream yardnya error.
Nggak bisa.
Dikloss aja ya.
Mau saya tab itu biarin aja.
Oh biarin.
Bisa dikloss ya?
Bisa.
Nah
contoh yang paling
sederhana adalah
kalau mau
low hanging fruit
database-nya diindex lah ya.
Ini ada contoh ya.
Jadi misalkan kita
apa, select
dari sebuah table
itu query-nya berapa
bisa pakai analyze, expand analyze
itu bisa ketahuan
landing time-nya
1,5
mili detik, execution time-nya
0,6
mili detik ini, datanya sedikit ya.
Tapi kalau udah kita bikin index
itu
bedanya berapa tuh?
Bisa hemat 1 detik.
Ya. Bisa hemat 1 detik.
Hati-hati-hati dengan index.
Iya jangan semua diindex ya.
Kalau semua diindex
cuma kayak mindahin
tablenya doang ya.
Iya buat apa gitu. Nggak guna.
Kalau semuanya diindex dia nyarinnya gimana.
Teman-teman di sini ada yang
Berarti kompleksitifnya sama aja
kayak pas awal.
Kayak pas nyari tanpa index.
Ada yang belum tahu
istilah index itu
cara kerjanya kayak gimana?
Oh belum tahu.
Index itu kayak
kayak buku.
Buku pages tahu
yellow pages.
Kalau kita mencari
Ada index ya kan?
Iya. Setiap buku itu ada index.
Jadi misalkan kita mau cari
mau cari apa ya
di yellow pages itu biasa ada
daftar toko.
Jadi
kalau misalkan kita mau cari
toko dengan
nama depan F
itu kita nggak perlu cari dari halaman satu.
Kita cukup cari
kira-kira di tengah-tengah sini C.
Nah itu index.
Jadi dia index berdasarkan
berdasarkan titlenya
atau kategorinya.
Terus nanti begitu dicari ya kita cari
berdasarkan yang kayak tadi, binary research gitu.
Binary research kan berarti
kayak dibagi setengah
di sini, di kiri
di A atau di B.
Kalau ada di B, dibagi dua lagi
di sini atau di sini.
Berarti gitu-gitu terus ya.
Mungkin implementasinya seperti itu.
Tapi yang jelas kalau misalkan
yang tadi ya, misalkan kita mau cari
alamat orang atau nomor
telepon orang
yang namanya adalah Z.
Kalau
nggak pakai index ya kita cari
dari A. Kita bukan dari A.
Tapi kalau di index misalkan
indexnya A, B, sampai
Z ya kita bisa cari
A, kita lewatiin. Oh B, kan ada
tandanya tuh.
Lebih sedikit
eksekusinya.
Gitu lah kira-kira.
Saya ada contoh
dunia nyata
yang saya
dengar pengalaman langsung
dari seorang direktur
operasi sebuah
perusahaan untuk penyewaan
mobil. Yang cukup
besar ya. Cukup besar.
Armadanya
ada sampe...
Perusahaannya yang besar.
Armadanya aja
di satu kota, mobil yang
mereka miliki asetnya itu
ada 15 ribu
mobil.
15 ribu unit.
Pertanyaannya, bagaimana
cara menyimpan
kunci seret
BPKB
dan STNK nya
inventarisnya secara baik dan benar.
15 ribu.
15 ribu.
Di mana coba?
Kunci seret, photocopy
STNK misalnya, atau
kunci seret dan
paperwork lah ya.
Kan harus ada satu unit, harus ada.
Pake filing ya, filing kabinet gitu.
Kalau misalnya
kalian bilang, oke pakai filing kabinet
terus kemudian dibikin sistem
pakai software, di mana nanti
posisinya. Jadi tinggal
set di sistem, oh nanti di filing
kabinet itu.
Itu katanya
super kompleks.
Too much work.
Udah bikin sistem, harus
bikin sistem yang
supaya synchronize, oke kalau
ada yang salah letak gimana?
Mampus nyarinya tuh.
Ya kan?
Dia cuma bikin sebuah
kabinet kotak
yang ada
100 ininya.
100 laci gitu ya.
Yang sesuai ukurannya.
Dan dinomorin
dari 00 sampai 99.
Jadi semua angka
plat.
Sesuai nomor STNK?
Ya sesuai nomor A plat itu 00
sekian-sekian. Jadi kalau misalnya
nomornya
988
ya udah berarti cari di laci
19.
Ya meskipun disana banyak, tetapi
yang kamu cari itu
yang ada
di dalam situ gitu.
Ya lebih mudah mencarinya.
Jadi systemize scan yang
sesuai dengan dalam kotak itu. Jadi dikategorikan
berdasarkan
2 angka di depannya
dia bikin.
Ya cari
tetapi
maksudnya tetap
butuh mencari. Mungkin di dalam situ ada
1000 kali kuncinya. Tetapi lebih mudah
mencari 1000 daripada mencari
yang salah letak. 1. Kedua
Error rate atau human error
untuk meletakkan sesuatu
di tempat yang salah
jauh lebih kecil. Karena dia udah liat
oh 99
ya sudah cari kotak 99.
Taroklah di kotak
99 barangnya.
Atau cari di kotak sekian.
Jadi dia menerapkan
hospital yang membuat
sistem operasional jauh lebih
jauh lebih
efisien.
Error rate dia rendah.
Nah itulah
kisah nyata indexing.
Indexing physical.
Ada
ada bidang
studinya sendiri kan. Katalogin
gitu kayak perpustakaan.
Ya makanya
dikategorikan berdasarkan apa gitu kan.
Ya betul.
Taksonomi. Supermarket.
Supermarket itu kan
banyak ya.
Dan mengkategorikan sesuai apa.
Berdasarkan itu berdasarkan
harga.
Produk.
Sorting ascending depan
paling murah.
Dibalik ya.
Cuma tanya, berarti
kalau di dunia database,
indexing itu berarti require
membutuhkan kayak
landmarkan semacam penanda
yang kayak ibaratnya
absolut dan nggak bisa diubah-ubah.
Dan cukup praktikal kan. Kalo contoh
kasus tadi apa? Yellow Pages
atau buku telpon.
Alphabet kan cuma A sampai Z.
Cuma ada 26.
Dan kalau emang namanya depannya Z kan
ya anggap aja kecil kemimpinan
udah ganti nama. Kalo pada saat itu
namanya depannya Z, ya udah kan
jelas. Nah terus kayak si
itu mobil nanti juga kan
STNK kan nomor plat kan
nggak berubah-ubah. Jadi kayak harus
ada itu kan pointer yang
Berubah dong.
Kalau terpanjang STNK.
Nomor plat tidak berubah.
Nggak ya.
Nggak berubah. Ya
berarti kan harus, berarti challenge-nya
mungkin pilih
unik key.
Unik key-nya
dicari, apa dibagi
berdasarkan desimal? Atau gimana
tuh? Misalnya range
itu tergantung sih primary key-nya
ya misalnya
di database, kalo di database
primary key
nggak mesti
eh sorry, index itu
nggak mesti primary key.
Tapi primary key itu udah pasti
diindex ya.
Kita bisa menambahkan index tambahan.
Yang unik dan nggak berubah.
Tapi kalo misalkan ada perubahan
dia direindex kan?
Yes.
Enggak indexnya ditambahkan.
Bukan ada perubahan.
Kalo ada perubahan direindex semua.
Enggak direindex semua.
Cuman diubah aja kan ini-nya
kan ya. Index table-nya
dia ada sendiri.
Si database tuh punya index table-nya
sendiri.
Kayak ada contoh
ini nih.
Contoh
lucu-lucuan nih.
Yang pernah saya
pakai untuk
interview
orang yang mau masuk ke
human way.
Buat yang mau interview
siapa tau besok gue interview Ivan.
Dikasih soal yang lain. Anda terjebak.
Window ya, window, window.
Window-nya gimana sih caranya?
Sudah?
Keliatan. Luka kita.
Panjang begini.
Ntar.
Kayak coba ini nih.
Kecil sekali.
Ya.
Kok ada item di atasnya ya?
Oh iya kok bisa sih.
Itu item di atasnya.
Enggak lah entah.
Rescreen aja lah.
Rescreen aja.
Kalau begini bisa gak?
Kalau cuma satu top aja.
Nah bisa ya?
Nah.
Jadi
ini kan carousel.
Anggap
ini membuat block
di dalam block editor-nya si WordPress.
Ada carousel.
Dimana satu ini
slide namanya.
Slide itu berdasarkan konten dari post.
Dan ada filter untuk mencari
untuk mempersempit
apa yang perlu
dicari di dalam slide ini.
Jadi hasilnya ini dipersempit oleh
filter.
Isi slide bisa
berupa post, bisa berupa kategori.
Jadi slide ini adalah
berdiri sendiri.
Ininya, itemnya.
Dia punya query custom ya?
Enggak sih enggak.
Enggak query.
Ini unit ini
bisa
recipe
atau post.
Bisa juga kategori itu maksudnya.
Dan
satu slide ini kan
carousel ya. Berarti dia tetap bisa
menambah tab. Ini ada tab-nya.
Tab 1, 2, 3, 4, 5,
sampai 10 juga mungkin bisa.
Atau terserah banyak
juga bisa.
Kemudian setiap tab tentu
harus diisi slide-nya.
Kebayang?
Notation-nya.
Jadi
isi ini
slide ini ada sendiri
dan setiap tab
ada sendiri.
Notation.
Gimana cara kalian
untuk
membuat
query-nya di front-end
mungkin bukan front-end secara
JavaScript. Anggap aja masih PHP.
Mengquery data ini.
Data yang disimpan
di setiap slide ini nanti adalah
ID dari post atau ID dari
kategori. Jadi mungkin
post ID 1, kategori ID 1,
post ID 2, kategori
2, kategori 3, gitu.
Disimpannya begitu.
Dan ada
pertanyaannya di front-end
bagaimana cara kalian melakukan
query-nya.
Bayang gak?
Ya kan harus diambil dari database.
Harus diambil
ke database, kan? Data ini kan.
Berarti bukan front-end, kan?
Ya maksudnya saat mau
ditampilkan, ini kan
di block editor, di ak,
di UI di depan,
kan harus di query
tuh.
Bagaimana cara mengambil
datanya supaya
big-one notation-nya kecil.
Masing-masing tab ada setting
filter-nya sendiri. Kepisah, kan?
Maksudnya, apa?
Misalnya di tab pertama,
kategori A.
Di tab kedua,
kategori B atau post.
Gak, gak seperti itu. Satu item ini
berdiri sendiri, jadi gak ada filter-filter.
Jadi anggap aja, kalau saya mau
isi ya, saya
cari. Oh, masing-masing item itu
kepisah, ya? Bukan
query, show,
post, kategori A. Semuanya? Bukan.
Gak. Satu item
berdiri sendiri. Satu unit sendiri.
Jadi bukan andal dari kategori
apa, taruh sini.
Tetapi bisa jadi,
ya, bukan
begitu. Jadi bukan diandal
dari satu kategori.
Bisa jadi, ini post,
tapi disebelahnya ini adalah kategori.
Sebagai satu unit.
Karena kategori kan bisa jadi,
bisa punya image, bisa punya nama.
Jadi sebenarnya,
di-show aja, nyempil aja gitu.
Ada mungkin Beef Wellington, ada Beef
Something Else apalah gitu ya.
Atau Dinner gitu. Beef Roasted.
Atau Carnivore.
Carnivore.
Nah,
kalau gue nih, ini jawaban yang
sesatnya ya. Maksudnya mungkin kalau
interview, mungkin ini ditolak.
Tergantung
data-nya sih, realistik,
realistik, tiap
ngambil satu, tiap nge-query post,
simpen di memori, terus
ngambil satu lagi, list of
kategoris, simpen lagi di memori.
Abis itu, next item
kan makin lama, makin
ringan kan, karena tinggal ngambil dari
yang udah disimpen.
Tapi kalau database-nya besar banget ya,
masalah baru lagi.
Itu satu jawaban
sesat. Kalau jawaban yang benar, apa ya?
Kamu
maksudnya,
gimana?
Kebayang nggak?
Nggak.
Nggak kebayang.
Kan maksudnya UI-nya, gue bayangin gini kan,
pas nge-quick gitu, untuk milih item pertama
kan harus ada list of posts
buat dipilih kan.
Nah, pasti ponenya semua itu gue bikin
kayak function lah, semua di pisasi function,
get post, get category,
get tax, atau taxonomy
apapun, yaitu setiap
menjalani ini, di cash,
setiap menjalani si function
getter ini, get post,
get category, get tax, di cash.
Nah, jadi kalau
habis itu buka lagi, get post,
itu kan udah kayak prepopulate, ada cash-nya.
Maksudnya yang tadi kayak gitu sih.
Kalau yang bener gimana, nggak tahu.
Belum ada ide.
Mau liat hasil akhirnya nggak,
contohnya kayak gimana?
Mau, mau, mau.
Ini jawabannya.
Karena ini udah jadi
sebenarnya projectnya.
Tapi didiadikan soal
untuk interview gitu ya?
Itu yang saya solve sendiri.
Itu maksudnya project yang
saya lakukan dan udah
selesai.
Saya share.
Oh ya, sorry, sorry.
Di fullscreen soalnya.
Ini situsnya.
Jadi lah, blognya.
Yoi.
Gue selalu ngajarin, ngajarin ini laper mulu.
Ini yang tanpa tab.
Yang ini tanpa tab.
Ini tanpa tab.
Ini yang ada tab-nya.
See?
Oh, isi pastas.
Fast and fresh.
Ya kan?
Dan itu nggak harus
semuanya recipe, bisa category, bisa...
Ya, bisa.
Ada nggak ya category ya contohnya ya.
Kebetulan datanya
tidak ada.
Tetapi sebenarnya
di dalam ini bisa nyempil satu category.
Ya, nggak ada.
Wait.
This one seems like a category.
No.
Oh, wait.
15 menit? Nggak.
Ya, so...
Bahasanya kayak gitu lah. Ini kan category.
Oh, ini. Ini category semua nih.
Tapi, nggak ada.
Karusele-nya nggak terbentuk karena nggak abis.
Gak panjang.
Kurang panjang.
Tapi sebenarnya ini karusele blog juga sama.
Oke.
So, kunci jawabannya.
Oke.
Saya bikinnya begini.
Kita zoom in
dulu ke satu blog ya.
Ke satu blog yang seperti ini deh.
Yang nggak ada...
Yang nggak ada...
Apa namanya?
Nggak ada...
Nggak ada tab-nya.
Nggak ada tab-nya.
Nggak ada tab-nya, maksudnya.
Yang saya...
Karena tadi ada dua entitas data.
Entity, satu post, satu category.
Maka dengan terpaksa
harus ada dua query ke database.
Karena satu ngambil post,
satu ngambil category.
Tetapi saya kumpulkan
semua. Saya kumpulkan semua
ID dari post
dan saya kumpulkan semua ID
dari category.
Saya query sekaligus
semuanya. Seabruk-abruk.
Dan disimpan
ke array.
Dan tinggal ditampilkan.
Nah.
Kalau misalnya dia
ke tab,
sama. Saya kan sudah punya
data post ID seluruh tab.
Dan saya punya
category ID dari seluruh tab.
Saya tetap melakukan
dua query.
Sama. Jadi jumlah query-nya tetap
sama. Selalu dua.
Get post by ID,
get category by IDs.
Now, let's
take a big picture. Karena
saya yang kendalikan halaman ini,
saya tahu isi
halaman ini ada berapa banyak
block
yang memakai karusel block.
Saya bisa query
seluruh halaman. Saya sebelum
dia ditampilkan. Saya
query.
Saya memparsing
konten untuk mengambil
dari block ini,
mengambil semua post ID
dan semua category ID.
Jadi,
untuk menampilkan satu halaman ini,
untuk seluruh karusel yang ada,
hanya butuh dua query.
Dua query.
Oh, sudah punya ID-nya ya?
Kirain itu tadi
user-nya. Maksudnya user dalam
arti work trace admin-nya,
kirain dia harus buka suatu UI,
milih dulu post mana
yang mau dimasukin, category mana
yang mau dimasukin.
Saat di admin, dia kayak gitu.
Saat di admin,
dia
satu-satu,
masukinnya satu-satu. Jadi, dia
pilih iris beef,
di-search iris beef,
masuk, kosok.
Oh, iya.
Itu di admin-nya sendiri
berarti ya. Maksudnya nggak bikin from scratch
yang milih itu.
Oh, ini bikin dari scratch. Ini react ini.
Ini bikin dari scratch.
Nah, berarti itu kan tetap harus
memanggil semua post juga kan
sebelum tahu ID-nya apa.
Yang user facing phone N ini
emang
sudah tahu ID-nya, jadi bisa
get post by ID 1, 2, 3,
terus abis itu
get category by ID juga.
Nah, tapi sebelumnya
pas di admin-nya kan harus
get all post dulu kan.
Iya, satu-satu. Dia tetap
harus search karena dia mau masukin apa
kesini dia mau punya full kendali
saat searching gitu.
Oh, iya, iya, iya.
Tapi ada faktor ini dong
semakin banyak data di database
akan semakin berat karena query-nya
walaupun 2, tapi jumlah datanya
kan bisa berpengaruh.
Karena sudah punya ID
dan ID-nya itu adalah primary key.
Jadi sebenarnya
post...
Maksudnya
post in atau query
in itu
lebih cepat sebenarnya
karena in-nya itu adalah primary key.
Lebih lama searching
by title, contohnya
yang tidak diindeks, tetapi
ini adalah query in
primary key.
Jadi sebenarnya...
Wah, berarti
kerja beratnya di klien dong
kalau datanya diambil semua?
Enggak, karena
tidak ada...
Ini server-side render
tidak ada...
Ini bukan client-side render
itu server-side render semua.
Jadi saya query
saya query
jadi punya array yang
cukup gemuk
jadi makan memori sebenarnya
tetapi ya, array-nya gemuk
tetapi waktu ngerender setiap
block, sebenarnya dia
sudah tinggal
hanya, sudah tinggal looping
sudah tinggal...
tinggal looping
berdasarkan si isi array
karena array-nya itu sudah diindeks
by
key dari
array itu adalah post ID.
Oh, berarti mirip kasusnya seperti
yang tadi diawal. Antara
kalau kita mau baca
file, apakah baca file-nya semua
dimasukkan ke memori, atau baca
file per baris?
Bedanya itu kan? Ini kurang lebih sama kan?
Karena kita sudah punya datanya semua
yang ada di memori
pasti lebih cepat.
Kita tidak perlu query lagi satu per satu.
Jadi beberapa
interviewer yang saya tanya
dia
pakai nesting loop
untuk
self-solving
tab aja
data per tab dia
nesting for loop.
Saya tanya lagi, kalau misalnya
satu halaman itu ada 10
karusel yang dipakai dan
setiap karusel ada 10 tab
dan setiap tab ada 100
item, berapa jumlah
dari mu?
Belulah dihitung-hitung, wah banyak banget.
Sebenarnya 3 tingkat
for loop
atau 10 for loop.
Setiap karusel
kan nested loop
tapi kalau ada 10 block
maka jadi 10
nested loop.
Saya bilang, berapa lama nanti
jadinya page itu ke render?
Kalau begitu caranya.
Lagian itu kan di PHP kan
pusing juga itu kalau nested loop-nya
di PHP
gak ke render-render.
Berarti, oke.
Make sense.
Itulah
gunanya
saya belajar di connotation.
Berarti emang ada kegunaan
konkret ya, bukan cuma buat biar
passing interview aja.
Fundamental ada gunanya juga ya
buat di...
saya tidak belajar
terus terang, kalau saya tidak belajar fundamental
saya akan masuk ke jebakan for loop.
Saya
saya solve satu
karusel dengan 1 tab
fine, tetapi begitu
dipakai di dunia nyata.
Tadi kan banyak kan karuselnya, minimal
ada 6 itu saya hitung tadi.
Kalau misalnya tiap
karusel 3
tab-nya, terus ada 10
itu ya eksponensial
itu kalau misalnya for loop.
Pasti minimal
3-5 detik
render page-nya.
Itu TTFD doang.
Gak bisa lag di loop.
Maksudnya in that particular case
kalau misalnya JavaScript kan
kalau user gak nge-scroll, ya gak usah
manggil dulu atau gak ganti tab
gak usah di render
dulu. Kalau ini lebih fatal lagi ya
berarti. Maksudnya apa?
Harus dipikir di awal.
Dengan cara teknik yang saya pakai
hanya 2 query
per page.
Menarik, menarik.
Untuk kisah nyata.
Wah, ini ada yang ketinggalan.
Referensi untuk teori
Big O, ada tadi di
awal-awal.
Di atas ada ini.
Medium.
Afart CS50 lecture 3.
Ada blog dari
saya juga.
Kalau yang bahasa Indonesia.
Ada beberapa yang lain, silahkan
di-check aja di ini.
Oh ini ya, CS3 ya.
CS50 ya.
Ini kuliah gratis.
Materi kuliahnya
gratis.
Penaruhin kuliah gratis tapi
gak pernah selesai loh CS50 ini.
Menentuk di
sesi ke-2. Jadi kan introduction
session 0, session 0.
Terus kuliah kelas
pertama, kelas ke-2.
Habis itu selalu ke distracted heline.
Tapi pendekatannya menarik ya tadi ya
yang kesnya Ivan ya.
Karena
by nature
atau ya naluri-naluri saya
gitu ya. Mungkin setiap orang
berbeda ya approachnya pendekatannya.
Kalau saya melihatnya, saya akan
bikin satu karusel itu
satu fungsi.
Jadi kalau ada 6 karusel, dia akan
memanggil 6, minimal
6 query. Karena pakai
fungsi kan. Misalkan
fungsi karusel
gitu kan. Terus habis itu yang dibutuhin adalah
oh pakai tab atau enggak, true
or false gitu kan. Terus di dalamnya nanti ada
query-nya. Query-nya berdasarkan
apa? Misalkan karuselnya berdasarkan
kategori atau berdasarkan pos.
Saya akan bikin seperti itu.
Tapi kalau... - Kalau mungkin itu mindset
JavaScript dev nggak sih? Kayak
yang kebiasa, ya udah
nanti, kalau dibutuhin
baru misalnya bikin
patch atau apa. Jadi kayak
per block, per UI
block, ada function, satu function.
- Betul, betul.
Kayak apa ya? Kayak mikirnya
kayak...
mungkin... - Unit.
- Unit, function.
- Iya, mikirnya unit. Jadi nggak keseluruhan
halaman.
- Itulah bahaya
yang apa dong?
- Tapi saya jadi tahu
perspektif. Kalau misalnya
ada tuntutan server
site, jadi kita harus optimize
di awal. Yang tadinya mungkin
mindset-nya lebih ke visual
block-nya. Satu
item, satu
function, satu query.
Gue tadi malah salah paham
sama soalnya dong
lebih parah lagi. Kirain pas lagi milih
item-nya.
- Oke. Ini juga apa ya?
Approach yang menarik
juga. Karena kan ada apa ya?
Beberapa tahun yang lalu, mungkin sekarang hype-nya udah
kurang ya. Beberapa tahun yang lalu kan
ada yang namanya GraphQL.
GraphQL itu kan dia menghindari
penganggilan data yang terlalu banyak
ulak-ulak timpong gitu kan. Karena ada
latensi dan lain-lain kan.
Berarti kechase ini juga itu
berguna kan
harusnya kan. Jadi dia ngambil semua
secara keseluruhan, terus baru
diolah di sisi klien-nya atau di sisi
front-end-nya gitu.
Jadi bisa lebih efisien.
- Cuma GraphQL itu kayaknya shifting
beban, ya maksudnya
mengoptimize-nya ke yang
apa? Orang yang nulis
service database-nya.
Apa? Yang bikin API untuk
untuk
dikonsumsi sama GraphQL klien itu
kan. Tetepkan software
harus dioptimize. Misalnya apa?
Kalau kita pakai REST API
kan kita get users, gitu.
fetch users, jalan
sekali, dibalikin daftar user.
Nah, terus abis itu
get pose kita yang
get pose by user ID kita
yang masuk-masukin. Sementara kalau di
GraphQL API kan kita bisa
minta user, di masing-masing
user, ada pose-nya
yang dimana
berarti kan itu sebetulnya dibalik layar
tetap harus gimana caranya
nyari semua, get pose by
user ID kan. Sebenarnya sama, cuma
sama. Tapi beban-nya
di-shifting ke
yaitu yang bikin API
lah.
- Iya, tapi kan istilahnya kita
manggil satu untuk dipakai
beberapa kali dibandingkan
kalau kita pakai satu untuk satu
karusel aja, terus yang kedua
karusel lagi, yang ketiga karusel lagi
kan di-kali 6
kan dalam kasus Ivan
tadi kan.
- Eh, coba ya.
1,
2, 3,
4,
5,
6, ya. Eh, 5
5 blocks.
- Tuhan, kebanyakan main di full stack ya.
Full stack WordPress ya.
- Sebenarnya, WordPress itu
kan cuma foundation-nya, tapi ujung-ujungnya
ya ph. Saya cuma
saya nggak melihat WordPress itu adalah sesuatu yang istimewa
karena ujungnya cuma php
javascript
react, kebanyakan
karena block editor
dan
lebih ke framework
kan sebenarnya ya.
- Tapi karena php framework
ya itu, jadi query-nya
kan harus di php, ya nggak harus
tapi by default.
- Maksudnya, query-nya sudah menggunakan
API-nya si WordPress kan.
Sudah, WP query,
WP post,
segala macam. Jadi sudah
objek-objeknya sudah
encapsulated. Ya, sebenarnya
sama aja
sebenarnya kalau mau terbiasa
pakai Laravel ya sama aja.
Kalau pakai Doctrine, segala macam.
- Oke.
Ada lagi yang mau dibahas?
Sudah cukup?
- Dari default sudah cukup.
- Dari kita sudah cukup. Kalau begitu
ditunggu
topik-topik
menarik lainnya di kesanain/
ngobrolin web. Ini juga salah satu topik
yang kita ambil dari GitHub ya.
Discussion
yang cukup banyak
diminta juga.
Jadi silahkan
langsung kesana untuk
apa namanya?
Untuk kasih-kasih ide
atau mau diskusi seputar
kerjaan. Misalkan tadi ketemu
coding interview
yang kayak Ivan tadi. Boleh disiap
siapa tahu, gitu kan.
Kemarin saya interview soalnya
kayak gini gitu. Solusi yang lebih bagus
saya nggak ketemu. Bisa diskusi,
bisa, bisa.
- Lepasnya pas lagi temen-temen interview
juga bisa dimana?
- Nggak boleh.
Jangan.
Jangan.
Kecuali yang interview-nya Ivan.
Ya, itu boleh.
Ya sudah, kalau begitu. Kita
Udahan untuk malam hari ini. Terima kasih
banyak buat semuanya. Kita
belajar cukup banyak ya.
Ternyata, padahal udah tahu lama
Biko, tapi
ternyata
masih banyak-banyak yang missing ya.
- Sejelas, tapi kayak concrete-nya tuh kayak nggak terlalu
merhatiin. Cuma yang "Oh ya, udah deh."
Maksudnya gitu.
- Gua hari ini belajar Omega Notation sama Theta Notation.
- Omega Theta.
- Karena biasanya kan
kalau di coding interview itu kan
yang
apa, yang menjadi contoh kasus
adalah
toy problem
kan, toy problem kayak palindro,
ya,
atau fist bus lah
atau apa, gitu kan.
Kalau yang real case kayak gini tuh menarik sih.
Jadi
istilahnya kita bisa dapat, apa ya,
snippet pada saat nanti kita kerja tuh
bakal kerjain ini, bukan kerjain palindro,
bukan kerjain anagram
dan lain-lain, gitu kan.
- Kecuali yang bikin aplikasi palindro.
Di HR perusahaan yang bikin
aplikasi palindro, fist bus.
- Iya, dan
kembali lagi,
kembali lagi ya,
harap berhati-hati
dengan apa ya, penggunaan
library, harus diperhatikan juga.
Misalkan contohnya,
ini bukan menjelekan ya,
misalkan di Laravel kan ada ORM,
ORM itu kan
tidak dioptimis untuk performance kan,
dia dioptimis untuk
developer experience kan, biar cepat,
gitu kan. Misalkan kayak
join,
apa lagi,
dan lain-lain kan, jadi
kita nggak perlu pakai query,
tapi dimudahkan karena
pemanggilan API,
gitu kan. Dan itu bisa berdampak
kalau datanya jumlahnya udah cukup besar,
itu bisa berdampak ke performance
karena
si query-nya itu harus dioptimis juga.
Dan biasanya itu ada semacam apa ya,
misalnya ya, semacam
jebakan. Karena kita udah biasa
menggunakan ORM yang ada
di bahasa pemograman masing-masing, baik itu
PHP, JavaScript,
Ruby,
dan lain-lain gitu, Python,
itu kita cenderung
operasinya itu, padahal sebenarnya
operasi di database itu bisa dioptimis,
tapi kita operasinya di kode.
Karena ORM-nya kan pakai
bahasa pemograman yang kita suka,
bukan SQL, kan.
Jadi kita cenderung terperangkap
ke situ, akhirnya kita bikinlah
looping lagi, bikin
lah filtering, dan lain-lain yang menyebabkan
performanya jadi semakin jelaj.
Jadi
mungkin kalau misalkan ada
teman-teman punya aplikasi
yang, kok ini lambat, atau
gimana, udah mulai ada komplain dari user,
yang pertama dilihat adalah
query dari ORM-nya udah optimis
sebelum. Karena saya yakin semua
ORM itu bisa support
raw query.
Jadi triknya
adalah, jalanin aja dulu join-nya.
Kan ada di konsol itu biasa,
di copy-paste, dioptimis, abis itu
diganti. Gitu.
Salah satunya.
Ada banyak yang lain. Index juga jangan lupa.
Tapi kebanyakan index juga
salah.
Gitu ya, untuk malam ini.
Kita ketemu
lagi minggu depan.
Minggu depan, tanggal berapa?
Mungkin, oh, minggu depan ya.
6, tanggal 6.
Mas ya, tanggal 6.
Ya, nanti.
Nanti kita lihat, mudah-mudahan bisa.
Kalau nggak bisa, kita
juburin, atau kita
jubur dulu.
Dan hantikan kejutan
dari kita bertiga.
Atau bahkan berlima.
Atau bertujuh.
Atau rame-rame.
Rame-rame.
Udah itu aja.
Terima kasih banyak untuk malam ini.
Kita ketemu lagi lain waktu.
Sampai jumpa
di lain kesempatan.
Bye bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Apr 2024
Ngobrolin Cache
Episode ini membahas topik caching secara komprehensif mulai dari konsep dasar hingga implementasi praktis di berbagai l...
3 Jul 2024
Ngobrolin Elixir
Episode ini membahas tentang Elixir, bahasa pemrograman fungsional yang berjalan di BEAM (Erlang Virtual Machine), bersa...
18 Jun 2025
Ngobrolin Database
Episode ini membahas Database Scaling, khususnya perbedaan antara horizontal scaling dan vertical scaling. Topik ini dia...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .