What happens is that the code fragment of the Mac PEF executable remains on disk in VM mode, and is demand-paged in. This requires less working memory because the entire segment need not be loaded, and as a result appears to make the app start faster, but the application can be paged out -- technically, its in-memory mapped pages will be marked as on-disk to make room for another app to use those RAM pages, since the code fragment is immutable -- as well as paged in which means that overall performance can be worse if a particular code segment is hot. The operating system can also be subject to this operation, worsening overall operation still.
RAMDoubler improves on this somewhat by compressing memory where possible so that more pages can fit in RAM, so it swaps less. If you have to use VM due to low memory (1400 or TAM in my case), use RAMDoubler.
With virtual memory off, everything is loaded into memory, including the OS. This uses significantly more RAM in some cases, but it will be a lot faster in the long run because nothing gets swapped out to disk and everything runs from physical memory. In fact, OS 8/9 won't even let you enable VM if you have 1GB or more of RAM.
Just to complicate things, applications with shared libraries (Classilla has a lot of shlbs) don't have them all mapped at once. The shlb is only mapped or loaded on reference, unlike apps that just have a big honking code frag. Classilla has to load a number of shlbs to get started, and these will all be separately mapped under VM.