Fabian Giesen

For a PC/Mac/Linux game, there's a real easy way to test: start a game to main menu, exit, start it again and time that second run. Is that second run at the main menu ~instantly? If not, it probably wasn't IO bound the first time either.

Because there wasn't any actual IO that second time. All that data was still in the disk cache. I promise.

Does you startup talk to a server on the Internet and need a handshake etc. that takes a while to complete? Cool. But not IO bound.

"But when I profile all the time is spent loading". Is that time in your data deserializers? A JSON/XML/CSV/whatever parser? Because none of that's IO either. That's all on the CPU. You're CPU bound.

Or is the time in zlib, LZMA, zstd, LZ4, LZHAM, Oodle, whatever? Also all CPU. You're still CPU bound.

Or are you loading a million tiny files or doing tiny reads? Then you might be bottlenecked by syscall overhead, or by bookkeeping in the OS VFS layer or filesystem driver. It happens all the time. But it happens on the CPU.

Is your load really damn fast and all that shows up in your profile is big bulk read calls that second time? Well done! But those big bulk reads turn into memcpys from the page cache. Done on the CPU.

If you're real sneaky you might be using memory-mapped files, so the kernel can map the data from the page cache straight into your process, zero-copy! No more bulk memcpy, congratulations! Now all the time is in the soft fault handler to populate your page tables. On the CPU.

Is it nothing to do with IO at all in your startup time? Awesome. Graphics context create? CPU. Shader creation? CPU. Sound init, scanning for gamepads, whatever? Good chance there's dubious drivers involved. Still all on the CPU side.

Anyway, that's the second start. The first start on a cold cache? Might actually be doing significant IO! But probably... still CPU bound. Everything is always CPU bound.

Bonus bonus rant: do you run one or three Windows FS filter drivers from some of the SDKs you need for work, or your corporate-mandated AV, that think it is a good idea to take a global lock on every FS operation, so file opens take 250ms on your 64-core workstation under load?