E foarte ‘the case’ cand latentele sunt cu trei ordine de marime mai proaste.
Pentru comparatie, ar prefera cineva un program cu latenta o secunda, sau varianta ‘no longer the case’ cu latenta 1000 secunde?
Mi se pare foarte tras de par articolul.
Intr-adevar, storage-ul e rapid. Dar nu peste tot. Si nu in orice limbaj si nu oricum. De multe ori inca ai exemple pe internet cu I/O sincron si ghici ce vor folosi incepatorii.
Era un fisier de 500Gb dat ca si exemplu si chipurile merge streamuit. Da, ok; e ceva basic. Dar poti sa-l folosesti asa in chunkuri?
Iar ca regula generala, “stay clear of I/O” merge bine intr-o companie. Nu vrei fiecare sa-si creeze fisiere temporare ca in practica te vei trezi cu o gramada de “hackuri” care se vor opri toate in momentul in care incearca doua procese sa scrie in acelasi fisier.
Sfatul asta ca un call de I/O e rau nu e neaparat legat de viteza (cu toate ca si asta e un factor major), ci de tot ce implica callurile la I/O.
Oh si ce consideram I/O in cadrul unei aplicatii? Ca daca vorbim strict de storage nu cred ca-i vreun bai. Dar I/O e cam orice call in extern aplicatiei tale. Baza de date, API extern, etc. De-asta “stay clear of I/O” e un bun sfat ca te fereste sa dai de pamant de baza de date ca “las’ c-are nvme” sau sa faci calluri scumpe la S3 ca “las’ ca aws e rapid”.
Or fi mituri chestiile strict legate de storage, dar am vazut ca au tinut multe proiecte in viata 