- If you want "super fast", put tons of files into a simple archive format (zip without compression, or tar). Low compression might also be faster in some cases which is the basis for NTFS compression (ample extra CPU cycles, for a lower data usage over the bottleneck of the disk).
- Another reason is because filesystem access is actually pretty slow. Dealing with many files, each with their permission check syscalls, etc.
- Put files on an SSD. Throw cheap hardware at it over smart algorithms since algorithms keep going.
- Put files on a RAM disk. (I have 32 GB on my system... it cost less than $100.)
- Only reload files that actually change. You could try something crazy like "rsync" to a cache of the file in memory, and only chance the actual data that's different. But I have no idea if the tradeoffs would balance in your favor the way they do for network connections.
I don't know. I mean, is loading bitmaps "that" big of a bottleneck on the driver side? I can't imagine any way to speed up / go-around the fact you'll "eventually" need to load a bitmap into a driver-specific format. Only load the graphics you need first, and load the rest in the background. There's no way the user needs EVERY bitmap possible in the game all at once. Even if s/he needs to "see" them all at once side-by-side, it'd still be mipmapped/thumbnailed versions. Even a 4K screen can only display... 4K... at once. So get the user what they actually want first, and bring in the rest, prioritizing what the user "might" click/view next (the next sequential image in a list).