Show HN: Nanosecond C message logger
Hello,
Some time ago I did a data logger for fun, just to check if I could beat the performance of an old C++ project of mine (mini-async-log) and to avoid letting my multithreading-C skills rust when on a non-programming gig (using Yocto/OE, very little programming).
This project is a BSD licensed, producer-wait-free (when using thread-local storage) generic message logger with high performance, decent test coverage, and type-safe C strings (requires C11 or C++ compiler).
It was a shame to let this project to die unknown, as I think that it has potential to be used on some niches as network programs, HFT, games, etc. so here I am sharing it.
https://github.com/RafaGago/mini-async-log
This was an evolution of a similar logger I did, this time I wanted to achieve wait-free producers, so this implementation can use thread-local storage to achieve that. Some other non allocation-free strategies are also available.
I still aimed for as easy as possible usage/learning curve and maintenance vs lots of features.
It has some interesting things too:
-It has one modification on Djukov's MPMC queue to make it MPSC and accepting variable (but limited) bucket size allocations (at the expense of unfairness towards bigger buckets). There are more modifications/variations on this Djukov queue on the library where I'm collecting all the generic stuff that I use when developing C programs.
-The project still maintains automatic type detection of the string formatters by using "clever" hardcore C preprocessor abuse mixed with C11 type-generic expressions. It still accepts most non-type printf modifiers. This is at the same time beautiful and ugly (you know what I mean), for the uglyness part, automated testing is available.
NOTE: Untested on Windows.
You seemed to have linked to the C++ version only.
The C repo: https://github.com/RafaGago/mini-async-log-c
Thank you. It's a shame that I can't edit the original post.
looking at your benchmarks, I see that you think glog is synchronous. This would be because you are logging at ERROR severity which does indeed flush. Logging at INFO would not have that issue.
Oh, I wasn't aware of that.
Good effort;
It's not just enough to have fast logging, it is also required to not abuse logging by having long, too many or useless messages.
Most people need a guide for 'The art of the log'. They should also know 'The art of the counters.'
Here’s a good post about it: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
Can you expand a bit? What do you mean by nanosecond? (1,10,100?)
My first thought was "Thirty centimeters seems a bit large for a message logger.".
On which machine?