It is absolutely normal. You can write an own bat file or use external compilation handlers like compilepal, but after compile is over, hammer is usable again. Anyway, why change the VMF if compile software is using it to make the bsp?
To elaborate, Hammer's default compiler still works in the background even when it's frozen - you just have to give it time to finish. CompilePal is a wrapper that uses the same compile tools but allows you to continue using Hammer while it's working.
IIRC cpal also grants instant access to the log, which the Hammer's frozen window obviously can't. It automatically packs custom stuff you put there (beloved feature), handles multiple configs well, has a friendly interface... extremely useful thing for, say, version compiles after changes are done. I and a lot of members would recommend it.
Compiling takes a lot of CPU, so improving your CPU could help, although that would probably be going a bit overboard. Optimizing your map will also help, especially if Hammer takes a long time to compile VVIS. A great tutorial for optimization can be found here: http://www.optimization.interlopers.net/ Keep in mind that a lot of this is unimportant until you get into beta; the most important thing is to remember to use func_detail wherever necessary. Here is the wiki page for func_detail: https://developer.valvesoftware.com/wiki/Func_detail
No it doesn't. The compile processes physically can't even use more than 4gb and they barely touch that except for sometimes VRAD.
I always use the -threads parameter set to 7 (quad-core CPU+hyperthreading so 8 threads of which I use 7) on VVIS and VRAD. Of course, because Source, instead of fully utilizing 7 cores it just drops to 88% usage on all cores, but it still leaves enough CPU time free for you to do other stuff.
Whoa. I seem to have read VERY old tutorials/docs, from the times not having 4gb was much more of a common thing.
