What is “memory mapping”?

A Problem Arises

Let’s use a texture as an example. When you load a texture, the computer does more work than you might think at first: The program has to allocate the memory for the texture, ask the OS for the corresponding file, and then the OS has to find, read and store the file’s data in memory. That phrase is a mouthful. (In reality it’s more complex than this, but I’m trying to not confuse you any further)

The astute might have noticed: to access this texture, instead of just reading its contents, the computer… copied it to a different place? The texture being in RAM makes it much faster to read of course, which is needed very often, but that’s not always the ideal way to go about it.

How come it’s not the ideal way?

Let’s go back to the last chapter, where I thoroughly preached for large, packed files. Depending on the game, these files could grow to be several GB in size. Now, if we don’t need to load the entire game at once (which will be the case for 99% of games) we can just read the parts of the file as needed, but this means we will have to manage assets ourselves, which isn’t only tedious to implement, but also introduces some overhead. (Overhead in this context just means that it “makes the task take longer”)

So it seems we have a problem, two problems even:

  • Efficiency - Although you might argue the difference won’t be noticeable, it impacts performance more than it might seem
  • Headaches - I speak from experience here, handling assets yourself is not fun. You have to know how big each allocation is, decide what stays in memory and when it stays or gets thrown away.

This is traditional file reading, the “manual” way. Don’t get me wrong here, there are benefits to it, like the control it gives the developer, and its undeniable flexibility, and many developers will even tell you this is the way to do it.

But you might want to do things a different way, the “memory mapping” way. Instead of the very manual process of asking the OS to find the file and copying it to memory, we ask it to do something else.

What’s the difference between doing it “manually” and using “memory mapping”?

The Differences

Let’s think of the file as a book. If you do things the “manual” way, every time your program needs to access a page (or a small chunk) it walks to the shelf and makes a copy of what it needs onto its desk, the RAM. Now your program can read what it needs! When it’s done, it might have to move some pages and chunks out of the way to make space for the next page.

If you use memory mapping, instead of walking to the shelf and making copies of whatever you need, you just ask the librarian for the book. The librarian then sets up the book on your desk, but oddly, this book looks empty. As you need to read a page, you ask the librarian for it, and it shows up magically in the book that appeared to be empty. As you ask for more pages, the librarian quietly moves pages in and out as needed, keeping everything efficient and never wasting space on pages that weren’t needed.

In code, it would look something like this:

# The "manual" way
file = open("big_assets.pak", "rb")              # Walk to the shelf
buffer = file.read_chunk("textures/player.png")  # Copy page to desk (RAM)
file.close()                                     # Release the book

# The memory mapped way
memory_map_file = memory_map("big_assets.pak")   # Book appears on desk
texture = memory_map_file["textures/player.png"] # Page magically appears as needed

Why should I use “memory mapping” instead of handling memory myself?

The Benefits

As my incredible analogy tries to describe, memory mapping solves both the headache and the efficiency problem. You don’t have to manually track or copy every asset you need, and you can handle large files without loading them all at once. The main benefit here is that we’re letting the OS handle the busy work, which, more often than not, the OS is better at than us!

Goodbye

Really, the TLDR for memory mapping is: Memory Mapping = treating files like they’re already in memory, and letting the OS handle actual allocation of needed contents, while we focus on the fun stuff.

Longest post so far… See you next time!