Comment 4 for bug 1492714

From the architecture perspective, pyroute2 is not of great performance (yet), though some optimizations are performed from time to time. The reason is that the primary requirement was to work w/o ctypes and other C hacks, thus we're limited to python strings and it leads to multiple data copying. But even with that limitation it can work a bit faster than external utilities:

$ uname -r
3.10.0-229.el7.x86_64

# the code creates an interface and adds adresses from 172.16.0.0/20 one by one with

# subprocess.Popen(['ip', ...])
$ sudo time python popen_profile.py
2.09user 5.22system 0:07.75elapsed 94%CPU (0avgtext+0avgdata 5156maxresident)k
120inputs+0outputs (0major+2320995minor)pagefaults 0swaps

# pyroute2.IPRoute()
$ sudo time python pyroute2_profile.py
2.19user 0.28system 0:02.70elapsed 92%CPU (0avgtext+0avgdata 12128maxresident)k
936inputs+360outputs (2major+5729minor)pagefaults 0swaps

on a RHEL7 VM

on kernels 4.x.x the difference is not so significant, but still exists: on massive ip addr operations the pyroute2 is faster.

…

But there are also other perspectives:

1. no need to parse text output, which format can be changed
2. no need to create a new process for a simple operation
3. less netlink overhead: every `ip addr add …` call actually leads to several netlink requests (load interfaces info, load addr info, apply addr info), while `pyroute2.addr()` is always one request — the state is kept by the program, no info loads for every address addition, e.g.

So anyway by working with netlink from the python process we do less overhead to the kernel, that can matter on heavy loaded system.

And the last is that with pyroute2.IPDB one can use sync states — with IPDB commits the system has a guaranteed state (if one can talk about any guarantee in the case of netlink). Though again, IPDB is not about performance, it is only about the system state.