My guess is that they're referring to the swap file. You can change swap file settings, and
http://www.musicxp.net/tuning_tips.php recommends that you manually fix your swap file size to be 2 times the size of your RAM. So if you have 1GB of ram, you would set your swap file size to 2GB (2,048 MB).
That checkbox essentially lets Live work more natively on Windows and make better use of the virtual memory capabilities of the OS. Technically, the difference is like this:
Checkbox OFF:
Live opens a file on the disk and uses the filesystem directly to stream data off the disk. Data probably always comes from the disk in small chunks and performance is very predictable because of it. This method also uses a very small amount of RAM for each file that you want to stream, so memory use is also very predictable.
Checkbox ON:
Live tells Windows to allocate enough *virtual* memory to hold the entire file, but also tells Windows to only load parts of the file as they are needed. Live can then access the file as if it were loaded entirely into RAM and it doesn't have to use the filesystem directly. Also, Windows can balance how much of the file is in memory at any given point in time based on how much physical RAM is available, how often the data is accessed, and in what way the data is accessed (i.e. always beginning to end or random bits here and there). Performance is potentially MUCH higher because it's possible, if there's enough RAM, that the entire file will be in RAM and the disk won't have to be used. This also means that the first time you play through, the disk will be used but every time after that the disk wouldn't (since data is loaded as it's needed, and will stay in RAM until the available RAM starts getting too low). BUT if you have more audio data than you have available physical RAM, Windows will start swapping data to and from the disk in order to maintain that "transparency" for Live to access the data as if it's already in RAM.
More detailed and probably confusing rambling:
The swap file allows Windows to create the illusion of much more RAM that is actually physically installed. If I have 1GB of physical RAM installed, and my swap file is 2GB, then each of my windows programs can have theoretical access to a full 2GB "memory" address space. I say "theoretical" because it all depends on how much ram is actually being used - if two different programs are both using 2GB of RAM then I'm going to run out of memory (since I only have 3GB available between RAM and swap).
It's limited to 2GB because that's the limit of a 32-bit number. That's also the reason why 64-bit OSes and processors are gaining popularity... the maximum addressable space increases to 2^64, which is roughly 18 billion GB instead of the paltry 2GB we get now

Plenty of space for the space age.
Windows uses swap space to temporarily store bits of memory that haven't been used in a while whenever memory starts getting low. For example, let's say you have 1GB of RAM installed and Live wants to load a 500MB sample but there's only 200MB of RAM left. Live will ask Windows to allocate 500MB of memory, and in order to accomplish that, Windows will try to "swap to disk" (thus, "swap file") any memory that hasn't been used in a while in order to free up more physical RAM. Normally what ends up getting "swapped out to disk" are things like your Yahoo Messenger or that USB detection DLL or other ambient programs or idle OS features.
BUT, what happens when RAM truely is TOO low and Live asks for more RAM than is available? Windows will try to accommodate by swapping out pieces of RAM as they are needed. So Windows will say, "Well, I've got ZERO free RAM but I still have 4GB of swap space left. I'll take 500MB of whatever this is and put it on disk so that Live can have its 500MB." Then the next time that peice of swapped-out RAM is accessed by Live, Windows will swap something else out so that it can swap in the previously swapped-out data... it's a vicious cycle, and it causes that annoying "disk thrashing" and everything takes forever to happen since disk is orders of magnitude slower than RAM (10 milliseconds for disk access versus a few nanoseconds for RAM).
I've probably made a mistake here and there but hopefully this will give you the idea.