#2312 snmpget makes excessive use of fgetc, VERY high overhead
I was profiling a system (using oprofile) that uses your snmp tools. For CentOS 6, /usr/bin/snmpget is in net-snmp-utils-5.5-27.el6_0.1.i686, which lists this project. When running oprofile, I found this:
8793 5.7621 libc-2.12.so snmpget fgetc
8793 99.0537 libc-2.12.so snmpget fgetc [self]
77 0.8674 libc-2.12.so snmpget __uflow
7 0.0789 libc-2.12.so snmpget _IO_default_uflow
I do have some scripts that make moderate use of snmpget. What's odd is that the third process from the top in terms of CPU usage is snmpget, calling the fgetc function. This is really high overhead.
In general, fgetc is an undesirable function to use. It's a function call, while getc is the macro equivalent. If you HAVE to get one character at a time, it'll be a LOT more efficient to use getc. However, it would be even better to get bytes in bulk using fread or similar.
It's probably simpler to switch to fgetc_unlocked(). That last function can be inlined, at least when using glibc.
Does commit b7e50d5f9a6755982d2af3191473cb34643bc03f help (applied on the v5.7 and master branches) ?
I'll have to try the trunk later. I'm afraid of breaking what I have in place right now.
But what I did was look for every fgetc and getc in 5.7.1.pre2 and replaced them all with getc_unlocked. Then I just overwrote the existing tools on my CentOS 6 Atom-based test machine.
Before, I had 5% or more of my system time dedicated specifically to fgetc in snmpget (according to oprofile). Now the biggest contribution of any snmp tools to system time is in libcrypto at around 0.17% of system time.
It was trivial to grep for this, and they were all in parse.c. Yay open source. :)