BSP is the file format supported by any Quake engine game, eg Half-Life. Compiling a .map file into a .bsp file sometimes takes hours - I believe my record time is about eight. However, you can reduce these times a great deal, and improve the technical side of your final map, just by understanding what each of the four compile tools is really doing, and increase your productivity at the same time. The mathematical details behind some of these processes are pretty complex, but I will be providing a strictly "need to know" overview for the typical mapper. I won't, however, be going into great detail about the different command line switches, for that is another node in itself.
The four compile tools are:
They often have a prefix, dependent on the individual game for which these compilers are designed, eg HLCSG. This should help you differentiate between different versions, but for the most part, they perform the same task.
The name of this compile tool is a reference to the form of geometry favoured by the Quake engine, constructive solid geometry. CSG simply means that you start with nothing and build into the void.
CSG begins the process of chopping up the world into convex polyhedra, and creates the first set of temporary files. It then passes control to...
BSP establishes the BSP tree that is best described here, and relies on the files produced by CSG. Therefore, CSG and BSP must always be run before the map itself will run. BSP produces the first "draft" of the map, although this will usually be crude and all but the smallest maps will run very slowly, due to unnecessary rendering.
This is where you have an element of choice. If you choose not to run VIS, the engine cannot know which faces of the map are visible, and which are not, and so it draws them all individually. This is clearly unacceptable for a release compile, but VIS can take a long time and so for internal test builds, it's sometimes advisable to skip VIS altogether.
The role of VIS is to move through every node of the map, which are the convex polyhedra that divide up the empty space that the player can occupy. At each node, it calculates all the possible faces that could be seen, and those that could not. This takes a long time, but it saves a vast amount of time while the game is running, because there are so many less faces to be drawn. This is reflected in the greatly reduced render times required for the map.
Applying RAD increases the size of the map file greatly, often two or three times over. It is also the slowest of the four compile tools, and so is typically left until all other aspects of the map are near-complete.
RAD analyses each light source, both point lights and light-emitting textures, and calculates the amount of light shed on each face of the map. In fact, for greater accuracy, it divides each face up into many sub-sections and calculates the light value for each one individually. Light can reflect off various surfaces and appear in a myriad of colours, as calculated by the Phong lighting algorithm; but this takes a great deal of CPU time for large maps.
Once a map has had light applied, it looks far more realistic, and aesthetically pleasing too. However, due to the large amount of time required to compile with RAD, the majority of mappers complete the other aspects of the map first and tweak the lighting last. RAD has a number of command switches that favour this progression of development, but that's another node altogether.
It is possible to run RAD without VIS, but RAD will typically take 30% - 70% longer to run in this case. I would advise running at least a Fast VIS before applying RAD, as it makes the lighting look better too.