G2log, the asynchronous logging utility I have been working on in my spare time is finally live and ready to download. An introduction and a performance comparison with Google’s logging library (glog) can be found at www.kjellkod.cc/g2log-efficient-background-io-processign-with-c11
The performance tests were made on a Dell Latitude E6500 laptop, Intel® Core™2 Duo CPU P8600 @ 2.40GHz × 2, with a solid state drive. On another system using a standard hard drive the difference between synchronous (glog) and asynchronous (g2log) would be larger.
The performance comparison is more about comparing the power of asynchronous operations to synchronous operations. Disk file access I/O wait times can be painfully long. This is clearly helped if done asynchronously, and punished if done synchronously
In a worst case scenario with a lot of data congestion the Google’s glog shows wait times of 1/2 second up to a whole second when flushing log entries to disk.
Kjellkod’s g2log gets leverage by doing slow disk access in the background. With the same worst case test setup the maximum wait times for a LOG call to finish was in the range of 13 – 113 milliseconds.
In a not so extreme test, but still with heavy LOG usage (1 thread writing 1 million log entries) g2log has maximum wait times of about 13 milliseconds. Google’s glog peaks at 459 milliseconds.
With these high times it can be good to know that the average time for a LOG call was much better. For g2log the average time was in the range of 6 – 9 microseconds.
For Google’s glog the average time was in the range of 10 – 13 microseconds. The log entries buffering that makes glog pseudo asynchronous clearly pays off. Google’s glog still achieves very good average time for being a synchronous logger.
From my testing it is obvious that an asynchronous logging utility outperforms a synchronous logger. Especially the peak wait times, when doing slow disk access, is mitigated if done in the background.
In addition to outperforming the traditional synchronous loggers g2log also provides some crash security. At shutdown g2log flushes all FIFO queued log entries to file.
In case of a fatal event, such as segmentation fault or floating point exception (and more), a signal handler will receive the fatal signal then notify g2log, which resends the aborting signal after saving to file all the pre-fatal log entries. The resent fatal signal will finally abort the application.
Too see how it is done, and to start using g2log you can go to http://www.kjellkod.cc/g2log-efficient-background-io-processign-with-c11.
G2log’s code is completely free, available as a Public Domain Dedication.