Thx, Ralgert
I fired up msys and got some results:
The first results were desasterous. Then I remembered that I shouldn't use the debug version of ufo2map
The first thing I noticed was that maps.mk doesn't seem to recognize the # of processors correctly, passing -t 1
So I gave -j 20. Result: 46 minutes.
I noticed that after some 30 mins, cpu went down from 100% and only a few maps were using up the last 15 mins. bunker and a_hangar were the last ones to finish even though they must have been started pretty early in the process.
Next, I forced -t 2 (by editing maps.mk) in order to reduce those last 15 mins. Result: 37 mins
Then I had the idea to start a_hangar asap, so I set -j 500. After some 10 mins, there were only a handful of processes running. After some 15 mins only one of them remained. Guess which. It ended after 22 mins.
Next, I forced -t 4. Result: 19 mins
I guess that sets up a new world record for compiling the UFO maps
Next try: -t 8 (the true # of 'processors' on my system. Result: 32 mins.
Seems to be too much overhead here.
I also got a 'memory allocation failure' here.
As a comparison: the compile_maps.bat takes some 50 mins on my system.
Management summary:
1. Destructavator: if you want to save time, use msys->make
2. We need to figure out why the makefile doesn't detect the # of processors
3. never ever use the debug version for a recompile maps
4. We should figure out why a_hangar and bunker maps take sooo long to compile.
5. This was on a Vista system. Needs to be verified for others.
Sidenote:
- I saw a lot of "missing carpet00n texture" msgs
I hope my findings will also help those who don't have the privilege to own a 4 core/8 processor computer to optimize their compile process.