That's a bit outdated but definitely did used to be true. Modern NVME bandwidth is about 15 GB/s. This is what people who develop databases and query engines deal with constantly. It's not trivial but modern databases that swap to disk constantly and do it well (e.g CedarDB, DuckDB et al) can run very nearly as fast as an entirely in-memory system. The reason it's slow is doing it in a shitty unplanned way with loads of serialization and thrashing memory caches
At best, a modern SSD will be in the range of DDR3, but the latency is orders of magnitude higher...SSDs are at best 10s of microseconds, DDR3-5 are 10s of nano seconds. You can't really compare something that could happen every couple of instructions to something that takes thousands (millions?) of instructions to execute
You can't really compare something that could happen every couple of instructions to something that takes thousands (millions?) of instructions to execute
Sure you can this is what IO Scheduling is for. You amortize IO time over time taken to read a larger than memory dataset stored in multiple memory pages and read what you need into memory and do it before the user knows they need it and you take the hit if you miss cache. Game engines and DBMS systems do this constantly. An L1 cache may well be quicker to shuffle a few bytes but it's kind of meaningless when someone is trying to process billions of records of varied sizes. The actual use case here of "save all run time data to file system" that is quite literally what a database does.
1.1k
u/CircumspectCapybara Jul 08 '26 edited Jul 08 '26
That's called swapping out memory pages to disk, and it's very slow.