seems to indicate that it might not (libpcap-mmap is Phil Wood's
version, not Paolo Abeni's version which is what's in libpcap 1.x, but
they might perform similarly):

The experience learnt from this experiment is:

• At 100 Mbit using a low-end PC, the simplest packet capture
application is not

able to capture everything (i.e. there is packet loss).

• During the above experiment, the host used for capturing packets
was not

responsive when the sender injected packets on the network.

• Out of the box, Windows and winpcap [winpcap], the port of libpcap
to Win32,

perform much better than other popular Unix-like OS.

• Linux, a very popular OS used for running network appliances,
performs very

poorly with respect to other OSs used in the same test.

• Libpcap-mmap [libpcap-mmap], a special version of libpcap that
exploits the
mmap() system call for passing packets to user space, does not
improve the

performance significantly.

• Implementing a Linux kernel module based on netfilter [netfilter]
improves the
performance significantly, but still under Linux most of the packets
are lost.
This means that Linux spends most of its time moving packets from
the network

card to the kernel and very little from kernel to userspace.

Mac OS X might behave *somewhat* similarly to FreeBSD, because they
both use BPF, but Luca seems to indicate that stuff below the capture
mechanism makes a big difference - one issue is that if you get one
interrupt per packet, your performance will suck at high packet rates,
so polling, which causes multiple packets to be picked up per (clock)
interrupt, can improve matters. I don't know offhand whether OS X's
drivers and networking stack do polling or any other form of interrupt
batching.

(I don't capture enough traffic to speak from experience - I mostly
either read capture files supplied to me or do small captures of
traffic to and from my own machine.)