Using
nice(1) is the traditional way to do something like that, when the CPU is the limiting factor. With modern CPUs, however, there's a good chance of the disk subsystem being a bottleneck. Compiling involves a great deal of random reading and writing to/from the filesystem.
Many standard desktop drives are optimised to be cheap, rather than for performance or reliability, so can very easily get bogged down by a heavy random workload. Don't believe the hype on the drive's spec sheet, e.g. a SATA-150 drive with internal peak transfer rate stated as 75MB/s or more sometimes actually delivers just 1–2MB/s under a heavy random workload. The drives can only deliver their advertised performance on long continuous and contiguous streaming reads (which is extremely rare under general purpose workloads). As soon as there's lots of head movement (seeking), you are lucky if they deliver 10% of advertised data rate. Compiling a large project (e.g.
make buildkernel or
make buildworld) guarantees lots of seeking as there are a huge number of individual inodes and data blocks involved.
top(1) will let you get a fair idea of whether it is saturating CPU.
gstat(8) will let you get a fair idea of whether it is saturating disk.
Lastly, be careful with kernel tuning. Recent versions of FreeBSD (and most recent versions of most Unix variants) really shouldn't need a great deal of tuning for many normal workloads. It is very easy to kill the performance through kernel tuning. Some of the tuning guides you may find on the web may well be out of date and counterproductive (e.g. some of the old advice for tuning the network stack actually kills performance on current versions). The days of tuning being a requirement before you could get good performance are essentially banished into the past, although there are exceptions to that. Current Unix versions should generally only receive the absolute minimum of kernel tuning, to address specific known / observed issues, or enable specific functionality that you understand and want/need (or similarly to disable stuff).
