>From the "thought so" files ...

A program I'm presently working on for a work project is supposed to
receive alert messages from suricata and talk to a Niagara packet broker
in order to block the corresponding TCP connection as dicated by some
policy. The packet brokers offers a HTTPS REST API for this. It doesn't
support keepalive, ie, each API request requires establishing a new
connection. The program itself is written in Perl. A test I just did
involved deleting 224 so-called egress filters on the packet broker
whose lifetime had expired as quickly as the corresponding API calls
could be made. This caused the corresponding Perl process to use about
10% of the available CPU time. It also emitted 12,252 diagnostic
messages during the cause of the deletions which went to both stderr and
syslog, the latter 'nowadays' being hijacked by the PoetterToy in order
to provide all kinds of features nobody needs when logging diagnostic
output of programs to text files. In order to do so, it used about 50% -
60% of the available CPU time while the deletions were taking place.

That's an 'optimized' (doubtlessly) C program supposed to Very Efficient[tm]
and it needs 5 to 6 times as much CPU time for logging text messages to
a file than program which prints these text messages needs fo doing
connection-per-request HTTPS request/ response exchanges with JSON
payloads at a frequenct of about 31/s.

An impressive step forward from a mere syslog implementation.

:->