Subject: file I/O and page faults

Before rendering anything, we must first load the assets file, which contains all in-game images. As observed earlier, the first frame takes significantly longer to load. Let's investigate why.

When memory is allocated, the address returned is virtual, not physical. Operating systems often defer allocating physical memory until it is actively used (e.g., read from or written to). Memory is managed in pages, typically 4 KB (4,096 bytes) on Windows. Only when a page is accessed does the OS map the virtual address to a physical RAM location. This mapping triggers a system interrupt, introduces latency, and creates a page fault - a non-negligible performance cost.

The first frame's slowness stems from numerous page faults during initial memory access. This highlights why minimizing dynamic allocations during runtime is critical. After the first frame, however, all memory is mapped, and no new page faults occur. The game uses memory arenas (pre-allocated pools), ensuring memory is reserved once at startup.

To quantify the impact of allocations on memory bandwidth (GB/s), we ran two tests:
Test 1 : Allocate memory each time a file is read.
Test 2 : Allocate memory once and reuse it.

Results:
Allocate each time:
Total time: 3.1826 ms
Min: 4.000 MB at 1.837 GB/s (1,027 page faults)
Max: 4.000 MB at 0.674 GB/s (1,034 page faults)

No allocation:
Total time: 1.6554 ms
Min/Max: 4.000 MB at 2.435 GB/s (0 page faults)

These results align with profiler data: eliminating page faults exposes the system's memory bandwidth limits . Let's now measure the hardware's theoretical bandwidth to contextualize these numbers.