System very slow while compile

I know that compiling a program requires a lot of machine, especially the processor. I've done a lot of adjustments in my system (tunning kernel, boot, and others..) and still remains very slow while compiling software. Is possible minimize this lag?

My specs; i3 2600 / 4GB Ram / FreeBSD 10-3
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).
I know it's purely anecdotal but to backup Murph's suggestions: I've noticed my macbook appears to be completely responsive when recompiling kernel, even though it's quite old (core 2 duo) but it also has an old intel SSD with good random I/O performance (max contiguous read/write throughput is o-k by today's standards but I care little about that).

I can carry on using my DE and browser or do something that's not excessively CPU intensive without any obvious slowdown.
Resurrecting old thread but I have the same experience:
ThinkPad X1 Yoga (1st gen, 2016) on Core i7 with SSD and FreeBSD: System slows down significantly with poor DE response when building something from ports.
MacBook Pro 2015 on Core i5 with SSD and MacOS: No problems at all.

Perhaps, the user processes are allowed to seize too much CPU resources by default?
Watch memory and swap usage. The only time I have slowness while compiling is when I run out of memory and the thing start swaping.
No, shkhln, that definitely has something to do with how resources are allocated. This X1 has faster CPU than the MacBook I'm comparing it with. Same amount of RAM, and comparable SSD performance. It spins the fan a lot, but it's definitely not a PoS machine.
System slows down significantly with poor DE response when building something from ports.

Limit the number of concurrent ports build jobs ... add MAKE_JOBS_NUMBER?=n to /etc/make.conf where n is the number of jobs to run. For my late-2009 Mac Mini (Intel Core 2 Duo 2.53GHz, 750GB Seagate ST750LX003 7200RPM hybrid drive, 8GB RAM) I use 2 otherwise it defaults to 4 and noticeably slows down X Window usage (eg web browsing, mail).
Thanks, trev. I've just learned that MAKE_JOBS_NUMBER uses the number of available CPUs (sysctl -n kern.smp.cpus) to set the default. Indeed, on desktop systems we might want to set that to a more conservative value, so nothing is wrong with my machine. It's just FreeBSD is optimized to seize all the resources by default when building ports. I wonder why port building jobs aren't launched with some sort of nice setting to lower their priority by default.