mjhjmtu

The best way to create a ram disk on linux is tmpfs. It's a filesystem living in ram, so there is no need for ext2. You can create a tmpfs of 16Gb size with:

mount -o size=16G -t tmpfs none /mnt/tmpfs

Linux is very efficient in using RAM. There is little surprise that you see little if any speedup with tmpfs. The largest pieces to read into memory (and thus able to slow the process down) are the tools (compiler, assembler, linker), and in a longish make they will be loaded into memory at startup and never leave it. What is left is reading in source (the writing out of the results won't slow you down, unless severely memory constrained). Again, comon header files will stay around, only the user's source will require reading. And that is unlikely to be more than a few megabytes. Creating a large RAMdisk (or even much use of tmpfs) can very well slow things down (by making the build memory constrained, the files on RAMdisk or on tmpfs can not be used directly from there).

The problem is that the maximum size of a ramdisk, more specifically of size of memory that can be accessed via the ramdisk driver is configured at compiletime, can be overwritten at boottime, but remains fixed once the kernel is loaded into memory. The default value is probably measured in Megabytes. If I recall correctly the memory for a ramdisk is reserved right when the driver is loaded, all ramdisks are the same size and there is are some 16 ramdisks by default. So not even you want a ramdisk size of 16G :-)

As stated in the other answer, tmpfs is what you want to use. Further, you won't win a lot by having your entire OS in a ramdisk/tmpfs. Just copy your builddir to a tmpfs and do your compiling then. You may have to ensure that all temporary results are written to a location thats in the tmpfs as well.

To make a large ram disk after boot, with no messing around with kernel parameters, this seems to work.
Use tmpfs, make a file, mount it via loop, and mount that via a filesystem:

mount -t tmpfs -o size=200M tmpfs temp/
cd temp/
dd if=/dev/zero of=disk.img bs=1M count=199
losetup /dev/loop0 disk.img
mkfs.ext4 /dev/loop0
mount /dev/loop0 temp2/

Probably a bit of performance penalty going through multiple different layers... but at least it works.

OP the amount of RAM is expressed in MB. So all you need to enter there is 16384. And then voila you'd be in business.

You can mount a ramfs filesystem, copy your project into it and work from there. This guarantees your input files are loaded in to RAM, and they will not be re-read from the much slower disk drive. However as you discovered, this is generally not a useful strategy. You already get the exact same benefit.

Ramfs is a very simple filesystem that exports Linux's disk caching
mechanisms (the page cache and dentry cache) as a dynamically resizable
RAM-based filesystem.

-- https://github.com/torvalds/linux/blob/v4.18/Documentation/filesystems/ramfs-rootfs-initramfs.txt

You can already trust your input files are cached in RAM, the first time they are read. Your output files are also cached, so that you do not wait for them to be written to disk.

There is no artificial limit on how much you can cache, how long it stays cached, etc. Caches only start to be dropped once you have filled RAM. Which cache is dropped first is chosen by terrifyingly elaborated algorithms. The first approximation, is we describe it as Least Recently Used. See What page replacement algorithms are used in Linux kernel for OS file cache?

Note your text editor will explicitly fsync() saved files to disk.

If you run tests of a program that involves fsync(), running these in a filesystem like ramfs may speed them up. Another strategy is to try and disable fsync() with eatmydata / nosync.so.

Some other operating systems might have specific limitations, that can be bypassed using a ramdisk. At one end, the lack of any file caching is why ramdisks were popular on DOS.

tmpfs

tmpfs works the same as ramfs, except that it can use swap space if you have one. I.e. if you need RAM for something else, the Least Recently Used algorithms may select data blocks from tmpfs and swap them to disk.

Most people stick with tmpfs, because it also lets you limit the total size, and shows the space used correctly e.g. in the df command. I'm not sure why this difference exists. The size limit in tmpfs protects you from accidentally filling your entire RAM and basically killing your system. It defaults to half of your RAM.

Other reasons why writes can slow down

The above is a simplification tailored to your case. The writes to files in your case should not need to wait for the disk. However there are some cases of writes that do. See the excellent blog post Why buffered writes are sometimes stalled. The most surprising case is a recent change to Linux called "stable page writes".