any process that forks and execs allocates more memory than it needs.
the fork technically needs to allocate as much memory as the program is currently using.
this means that if you have a 512MB firefox process that needs to exec a 64k program to handle some mime time, you first allocate 512MB of additional memory, then exec the 64K program (at which time 511.95M of ram will be freed.
it used to be (in the bad old unix days) that when a fork happened the kernel would take the time to copy all 512MB of ram, only to throw it away a few ms later (the vfork call was invented to tell the system that it wanted to fork, but not really as a work-around for this)
modern *nix systems instead go through and mark those 500MB of memory as Copy-On-Write (COW), which isn't free, but is _FAR_ cheaper than actually touching all the memory (in extreme cases it changes from touching all 1G of ram (512MB of read, 512MB of write) to touching 16K of memory (1 bit per 8k page). this is a phenomenal speedup ( and it gets even better when you consider the amount of cpu cache that you avoid corrupting in the process.
in cases where the system doesn't exec something else you can get drastic savings due to the fact that the memory pages that contain the binary you are executing never change and therefor you never need to copy them. this is similar to the memory savings from doing threading, but without the risk of one thread affecting another thread