I think Nmap is by far the best portscanner around if you want to do some serious port-scanning. Nmap performs a DNS resolution by default. This is good for obtaining the fully qualified domain names (FQDN), however, in some cases when you are scanning huge networks spanning several class Bs, it can have a significant effect on the duration of the scan.
Although using the -n parameter can completely stop nmap from performing any resolutions, but sometimes there’s that fine granularity that you need, i.e., you want to perform name resolutions but not if it exceeds a certain amount of time. I have to say that I wouldn’t have even craved for such an idiosyncratic feature, had it not been for nmap. Fyodor has been awesome enough to provide fine-grained control over port-scanning to your heart’s content.
So I opened up the nmap code, trying to figure out if I could fine tune that feature myself and I was not at all surprised that there were several comments in the code that would give you the impression that the authors of nmap have been considering this feature.
At this time it seems that the timeouts for the DNS servers are being read out of an arrayname:
static int read_timeouts[][] in nmap_dns.cc.
The way the code works is, this array has retransmission timeouts. Each row of this array represents what retransmission timeouts that nmap will follow depending on the number of DNS servers provided.

In nmap 4.76, therefore, if you specify one DNS server (or only one entry exists in /etc/resolv.conf) nmap will wait 4000ms, then another 4000ms followed by 5000ms before giving up. But if you do specify two DNS servers, then for the first DNS server the timeouts are 2500ms followed by 4000ms and then the same is tried for the 2nd entry in the DNS servers. Therefore, it seems that nmap will wait 13 seconds at max before giving up on the DNS resolution of a host. Imagine scanning a class B and having to wait 13 seconds for each of the hosts to resolve. It would be a significant overhead.

Of course, one can find other things to do if the IP address space is not DHCP, e.g., starting a separate list scan (-sL) and a portscan (with -n) simultaneously so that the DNS resolution timeouts do not result in a major impact as far as the portscanning itself is concerned.
There could be pros and cons to this as well which I may have failed to consider. But at this time it seems that it might be the most judicious approach.

Ever since I installed Tortoise SVN I saw that the right-clicks on my Windows XP SP2 had been terribly slow. It seems like Tortoise performs a whole lot of caching. Every time you right click all the cache entries are browsed and updates are sought. Although, the interface provides ways to disable this overlay caching, it seemed to me that the caching was being performed regardless. I had to uninstall the client to restore the sanity of my right-clicks. I guess software designers should make design decisions such that the UI responsiveness is not compromised for Windows Shell extensions.