Comparison of logging libraries

• Offer a C ++ logger? (C ++ logging framework suggestions)
• What is the most efficient thread safe C ++ logger? (What is the most efficient thread-safe C ++ logger)
• Logging library for c games
• Asynchronous thread-safe C ++ logger? (Asynchronous thread-safe logging in C ++)

Motivation

1. For the first group, this article will give a more extensive comparison of loggers than the recommendation “logger X is the best for me”
2. For the second group, the article will give an idea of ​​the current level of technology and may tip the scales in the direction of “easier to use ready-made” or “oh, a lot of work, but I can do better” and who knows, maybe another year we will see a breakthrough in this area.
3. For the third and most pedantic group, I hope this article will save at least one of the 3 weeks of research, across the industry it can be an impressive number of man-hours

Loggers and their basic parameters

1. Pantheios
2. Glog
3. log4cpp
4. P7
5. G3log
6. Spdlog
7. Easylogging
8. Boost.Log (part of the huge Boost library)

1. Own license www.boost.org/LICENSE_1_0.txt
2. www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/installation.html
3. There are a number of other platforms and compilers on which Boost can be compiled, but they are not officially supported and will probably require additional effort.

Documentation and dependencies

1. Low dependency - part of the code depends on third-party solutions, but does not prevent compilation, and only partially restricts the functionality.
   
   
2. Header file only - the library is distributed as one or more header files that must be included in each source file of your program; in the case of Easylogging, the compilation speed is significantly reduced. But there is a way out of this situation - to compile these projects in the form of a library and connect it already, though this will require additional time to create a project.

Logger type, memory control and thread safety

• Synchronous - calling Log (..) functions and writing to a file occurs synchronously from one thread
• Asynchronous - a call to the Log (..) function only updates the message queue, and another thread is writing, thus reducing the call time of the Log (..) function from the user stream, and as a result, the maximum performance of the user stream is reached and the log call delays are minimized (..) functions.

1. Type number 1: Some believe that the call to the Log (..) function must be atomic, and thus the order of the log messages in the file will be consistent in time 00:00 -> 00:01 -> 00:02 and so on.
   
   
2. Type # 2: Others believe that in order to achieve maximum performance, you can sacrifice the atomicity of the call to the Log (..) function and accept the fact that the log messages in the file will be intermittent, for example 00:00 -> 00:05 -> 00 : 01.

1. Asynchronous mode is in experimental state.
2. Timestamps and messages are not mixed.
3. Timestamps and messages may be shuffled.
4. The default is not available, you must activate the macro ELPP_THREAD_SAFE
5. Uncontrolled memory allocation, with high loads can allocate hundreds of megabytes, author's comment: kjellkod.wordpress.com/2014/08/16/presenting-g3log-the-next-version-of-the-next-generation-of-loggers
   

   This is a std :: queue is used internally that is a std :: deque. It is unbounded but much more memory tolerant than a std :: vector. Internally the queue is wrapped inside the shared_queue.hpp.
   

   
   
6. You can set the queue length in the elements, the size of the element in the initial form - 88 bytes + text message (30-160 bytes). The author recommends setting the queue size to 1 million messages for optimal performance, which translates into memory consumption from 120 megabytes to 250 megabytes only for the logging library.
7. The order of messages is not guaranteed by the library by default, time stamps can be mixed in the final file when logging from different streams: “Why does the log record have a multithreaded application?” The author of the library suggests using “unbounded_ordering_queue” to overcome this problem using special . attribute "RecordID" which will be sorted
8. By default, the library uses “unbounded_fifo_queue” which results in an uncontrollable increase in memory consumption during intensive logging. It is possible to use with the additional setting “bounded_fifo_queue”. In this case, you can set the queue length in the elements. Each element (record in library terminology) occupies about 1KB

Process Failure Handling

• Automatic, the library itself adjusts all vectors and will do everything itself, a big disadvantage of such a solution is the paucity of intercepted signals, as well as interference for an application that perhaps would like to handle the crash itself in order to save a crash dump file or flush buffers.
• Manual — the library provides primitives for intercepting crashes and flushing buffers, and the application itself decides when and how to install an interceptor and what to do in the event of a crash.
• Let him fall, everyday life

1. The following signals are intercepted: SIGSEGV, SIGILL, SIGFPE, SIGABRT, SIGBUS, SIGTERM.
2. Intercepted following signals: SIGSEGV, SIGILL, SIGFPE, SIGINT, SIGABRT, SIGBUS, SIGTERM, SIGBUS, PureVirtualCall, VectoredException, Newhandler, InvalidParameterHandler, status_access_, exception_array_bounds_exceeded, exception_datatype_misalignment, exception_flt_divide_by_zero, exception_flt_stack_check, exception_illegal_instruction, exception_int_divide_by_zero, exception_noncontinuable_exception, exception_priv_instruction, exception_stack_overflow
3. The following signals are intercepted: SIGSEGV, SIGILL, SIGFPE, SIGABRT, SIGBUS, SIGTERM, Div by zero, illegal printf, out of bounds, access violation, std :: future_error
4. github.com/gabime/spdlog/issues/55 - The defect was “closed” in 2015, i.e. No work is foreseen in this area.
5. The following signals are intercepted: SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGINT
6. Even for synchronous mode, there is a risk of data loss in the event of a process failure; in the case of asynchronous mode, the risk of data loss is extremely high.

Logging style and output (sink)

• Functions with variable argument list (prinf style)
• Overload of the operator “<<”

1. In the case of the use of "Printf" generated an exception, this is probably a temporary problem.
2. Own server is used for maximum performance. The server is free, but unfortunately only supports Windows, apparently based on Qt, a request for Linux support was sent to the author. The speed of sending logs over the network in the test configuration was about 3.5 million per second when the CPU was loaded - 13%. Performance tests are discussed in detail in the following chapters.
3. The official delivery does not include Sink with support for file rotation and the console, but these extensions can be downloaded github.com/KjellKod/g3sinks
4. Format string for Printf library functions is not compatible with the canonical format, which significantly complicates the painless replacement of one logger with another
5. Passing a nullptr string as an argument to the logger causes a segmentation fault / access violation
6. Most productive Sink: Binary file, Baical

Initialization of logger

1. Detailed and well-organized setting of the parameters of the logger, perhaps the most extensive of all.
2. In all other loggers, in order for the command line parameters to be processed, you must transfer them to the logger by hand from the int main (int argc, char * argv []) functions. In this logger, these parameters can be intercepted automatically from any part of the program / module (dll, so).
3. The library provides only the most basic primitives for configuration via the configuration file . A more complete discussion of this issue can be found at the link. And as a conclusion

   This is a list of It is impossible to give an explicit configuration format description.

Filtering setup

1. To organize the filter you need to develop your FrontEnd
2. Supported only if the data is sent over the network, in the case of recording to a local file, the server does not have access to the Verbosity level
3. In addition to the global level, you can set the levels for each module.
4. Hierarchical logging and setting of levels individually for each logger
5. By default it is disabled, it is activated by the macro G3_DYNAMIC_LOGGING, then you can manually set the level for all loggers. Significantly reduces performance.
6. The support is declared by the manufacturer, but it was not possible to get it to work, during use, the impression was that the function was under development or abandoned.

Unicode support

1. Almost perfect, except that the final log file does not have a Unicode marker and the encoding in the viewer will need to be selected by yourself.
2. Support is stated, but not implemented, unicode characters do not fall into the log file.
3. The macro START_EASYLOGGINGPP does not support unicode
4. In a single message, you cannot combine an ANSI string, say with UTF-16
5. Unicode support is carried out using the Boost.Locale library, impressively wide support is provided for various UTF-8/16/32 formats and other national locales, unfortunately, Boost.Log was only able to get to work with the UTF-8 file format and only using the initialization function synchronous logger "logging :: add_file_log", all other attempts failed and unicode characters did not reach the file, perhaps with enough time, this functionality can be made to work

Access to the logger

File rotation

1. Each file in the title contains the date and time.
2. Supported option is “max. number of files "allowing you to store only the last N files

Time accuracy

1. Sometimes you can get a granularity of 1 millisecond, but much more often a quantum is 10 milliseconds.

Performance

• in default configuration
• in terms of equal memory usage
• in single stream mode
• in multi-thread mode

• Window 7x64 (6.1.7601 Service Pack 1 Build 7601)
• Visual studio 2015, update 2
• RAM: 16Gb (DDR3-1600 / PC3-12800)
• CPU: Intel Core i7-870
• HDD: Samsung EVO SSD 850 256GB (SATA3)

• Message number
• Source file name
• Code line number
• Source function name
• Logger / Module Name
• Level (error, warning, ...)
• Time
• Current thread ID (thread Id)
• CPU core number
• Text message

#include <stdio.h> #include <atomic> #include <thread> #include <vector> //Include specific logger headers #include "Logger headers ..." using namespace std; using namespace std::chrono; //Use this macro to switch on multi-threading mode //#define MULTI_THREAD int main(int argc, char* argv[]) { //Logger initialization //.. unsigned int thread_count = 4; unsigned int howmany = 1'000'000; vector<thread> threads; auto start = system_clock::now(); #if !defined(MULTI_THREAD) for(unsigned int i=0; i < howmany; i++) { //Has to be customized for every logger LOG(INFO) << " Message + all required information, #" << i; } #else howmany /= thread_count; for (int t = 0; t < thread_count; ++t) { threads.push_back(std::thread([&] { for(unsigned int i=0; i < howmany; i++) { //Has to be customized for every logger LOG(INFO) << " Message + all required information, #" << i; } })); } for(auto &t:threads) { t.join(); }; howmany *= thread_count; #endif auto delta = system_clock::now() - start; auto delta_d = duration_cast<duration<double>> (delta).count(); LOG(INFO) << "Time = " << (double)howmany / delta_d << " per second, total time = " << delta_d; //Logger uninitialization if necessary return 0; } 

One thread

1. Asynchronous logging
2. Compiled with the option “/P7.Pool=1024” - the total amount of available memory is 1 megabyte.
3. Measurements can be considered synthetic, since most of the time the logger adds the data to the buffers, and recording occurs upon exiting the application and this work takes time exceeding the logging time by an order of magnitude, 1 second logging and 10 seconds of saving data.
4. Logging under the conditions recommended by the manufacturer “spdlog :: set_async_mode (1048576)” while the logger consumes about 250 megabytes of memory
5. Logging in conditions of equal memory consumption “spdlog :: set_async_mode (4096)” - in this case, the logger has a buffer of 4k elements, each element takes about 250 bytes, which ultimately results in a memory consumption of about 1 megabyte.
6. Recording was carried out in a binary file, text in UTF-16 format
7. Logging in conditions of equal memory consumption (asynchronous_sink + text_file_backend + bounded_ordering_queue + block_on_overflow), the queue length is 1024 elements, each element takes about 1100 bytes, which ultimately results in a memory consumption of just over 1 megabyte
8. Synthetic test. Logging in the most comfortable conditions, default logger configuration (asynchronous_sink + text_file_backend + unbounded_fifo_queue). There are no restrictions in memory consumption, there is no sorting of messages in the order of receipt, the memory consumption was fixed at 1.8GB

4 threads

1. Asynchronous logging
2. Compiled with the option “/P7.Pool=1024” - the total amount of available memory is 1 megabyte.
3. Measurements can be considered synthetic, since most of the time the logger adds the data to the buffers, and recording occurs upon exiting the application and this work takes time exceeding the logging time by an order of magnitude, 1 second logging and 10 seconds of saving data.
4. Logging under the conditions recommended by the manufacturer “spdlog :: set_async_mode (1048576)” while the logger consumes about 250 megabytes of memory
5. Logging in conditions of equal memory consumption “spdlog :: set_async_mode (4096)” - in this case, the logger has a buffer of 4k elements, each element takes about 250 bytes, which ultimately results in a memory consumption of about 1 megabyte.
6. Recording was carried out in a binary file, text in UTF-16 format
7. Logging in conditions of equal memory consumption (asynchronous_sink + text_file_backend + bounded_ordering_queue + block_on_overflow), the queue length is 1024 elements, each element takes about 1100 bytes, which ultimately results in a memory consumption of just over 1 megabyte
8. Synthetic test. Logging in the most comfortable conditions, default logger configuration (asynchronous_sink + text_file_backend + unbounded_fifo_queue). There are no restrictions in memory consumption, there is no sorting of messages in the order of receipt, the memory consumption was fixed at 1.8GB

Filtration

1. Filtering is not available by default.
2. Couldn't make filtering work

Performance review

((1,000 ms / test time in ms) * 1,000,000 messages) / use CPU in the test

findings

Pantheios

• Type-safe pattern-based calls
• Good and complete documentation.
• One of the few loggers that supports unicode, but with some limitations
• Low memory consumption
• A large number of supported Sink
• A large number of supported compilers

• Development seems to be stopped
• Static linking during compilation of the logger and sink (file, network, etc.)
• Incredibly long compilation even on powerful computers and as a mediated result - the size of binary files
• One of the lowest performance indicators of all loggers reviewed.
• Logger configuration in code only (no configuration file support, command line ...)
• No file rotation support
• Synchronous execution, i.e. all delays Sink (write to the file for example) will affect the speed of execution of your code.
• It is not possible to combine unicode and ANSI strings within a single message.
• High threshold of entry (difficult enough to learn and confusing)

1. C ++ Diagnostic Logging Critical Diagnostic Logging Cards (up to two orders of magnitude) www.pantheios.org/essentials.html

Glog

• Easy-to-understand library
• Process failure support
• Ability to configure via the command line
• Low memory consumption

• Very weak documentation
• Weak support for process failures - limited signals, only Linux
• High overhead when filtering messages
• Repeated gap (up to 9 times) in performance of Debug and Release code
• Synchronous execution, i.e. all delays Sink (write to the file for example) will affect the speed of execution of your code.
• Active development suspended
• No unicode support
• Timestamp accuracy is insufficient
• Highest CPU consumption in multi-threading tests with a very modest logger performance gain compared to thread 1

log4cpp

• Generated documentation
• A large number of supported Sink
• Low memory consumption
• Configuration file support
• Good message filtering performance

• Synchronous execution, i.e. all delays Sink (write to the file for example) will affect the speed of execution of your code.
• No unicode support
• Repeated gap (up to 10 times) in performance of Debug and Release code
• Low performance (last place)
• Line size should not exceed 1024 characters - otherwise assertion
• If the path to the log files does not exist, an exception is generated.

P7

soft

• Complete documentation
• High performance + high precision timestamps, a large lead over the closest competitor SpdLog
• Unicode support
• Full control over memory consumption
• Asynchronous - the call to the Log function is independent of the data record, thus delaying the call to the function.
• Using Shared memory (instead of “global” variables) to access loggers and Sink, which allows you to access the logger from any parts of the process code, even from dynamic modules written in other languages ​​supported by the library, such as C # or C
• The kit includes wrappers for C, C #, Python
• In addition to logs, the library supports recording and monitoring in real time.
  
  telemetry

  
• The ability to control remotely (via the network) the logging level on each device, process or module, enable / disable telemetry counters
• Of all the considered loggers, there is a minimum processor requirement in terms of performance.
• Available for several languages ​​and if different parts of the application are written in C #, C ++, C, they can all use the same logger
• Easy to connect your own Text Sink
• Wide selection of Sink
• The Baical server core is an open source project and can be compiled under Windows, Linux 32/64

• Highly intensive use of a multi-stream logger reduces (by a factor of 2.3) the performance of the logger (charge for a sequence of log messages and timestamps)
• Developing your own binary binary data Sink
• Due to the serialization of the log messages, it is not possible to load all the processor cores evenly

G3log

• Good filtration rate
• Handling process failures (generation of stack trace when information is available), unfortunately only under Linux
• Overall satisfactory documentation
• Asynchronous - the call to the Log function is independent of the data record, thus delaying the call to the function.

• No unicode support
• Poor performance, with high CPU consumption
• Performance measurements can be considered synthetic, since most of the time the logger puts the data into buffers, and the recording occurs upon exiting the application and this work takes time exceeding the logging time by an order of magnitude
• Full asynchrony - timestamps and messages can be mixed in groups or one at a time with intensive logging
• Uncontrolled memory allocation reaching hundreds of megabytes, sometimes gigabytes with intensive logging
• Logger configuration by code only
• Timestamp accuracy is insufficient
• Repeated gap (up to 30 times) in performance of Debug and Release code
• High CPU consumption
• Compilers with C ++ 11 or higher

1. kjellkod.wordpress.com/2014/08/16/presenting-g3log-the-next-version-of-the-next-generation-of-loggers
2. kjellkod.wordpress.com/2015/06/30/the-worlds-fastest-logger-vs-g3log

Spdlog

• Overall satisfactory documentation
• Not exacting to the processor
• Asynchronous - the call to the Log function is independent of the data record, thus delaying the call to the function.
• Partial control of memory consumption
• Good set of helper macros
• Speed, second place in the overall standings, but the backlog from the first place is a colossal

• No process failure handling
• The format string for Printf library functions is incompatible with the canonical format, which makes it difficult to painlessly replace one logger with another, in fact it’s a one-way ticket
• Full asynchrony - timestamps and messages can be mixed in groups or one at a time with intensive logging in the final file
• For optimal performance, it consumes about 250-300 megabytes of RAM, while reducing the amount of memory, performance decreases by almost 18 times.
• No unicode support
• Only header files that I attribute to minus, since the inclusion of these files in each file of your project significantly slows down the compilation, it is possible to use precompiled headers
• Logger configuration in code only
• Accuracy of timestamps is insufficient, especially in the light of achieved performance (tens and hundreds of thousands of messages per second with a timestamp resolution of 1ms)
• Compilers with C ++ 11 or higher
• Multiple break (up to 74 times) in performance of Debug and Release code

Easylogging

• Overall satisfactory documentation
• Not exacting to the processor
• Moderate memory consumption
• Good set of helper macros
• Support configuration file command line
• Declared a large number of supported platforms

• Synchronous execution, i.e. all delays Sink (write to the file for example) will affect the speed of execution of your code.
• Poor performance
• Failed to start filtering, perhaps the option is under development
• Unicode support is declared, but in fact Unicode characters do not reach the file and are lost on the way.
• Only the header file, which I attribute to the minus, since including it in each file of your project slows down the compilation significantly, it is possible to use precompiled headers
• Timestamp accuracy is insufficient
• Compilers with C ++ 11 or higher
• Multiple break (up to 40 times) in performance of Debug and Release code
• It is necessary to enable thread-safety with a special macro (ELPP_THREAD_SAFE), disabled by default

Boost.Log

• Support for synchronous and asynchronous logging (calling the Log function is independent of writing data, thus delaying the call to the function)
• Good enough documentation covering basic needs.
• Log record attributes (stream number, source file, counters, etc.) simplify logging
• Supported per sink formatting
• Ability to use predicates to filter
• Declared a large number of supported Sink
• Unicode support
• Configuration file support

• One of the most complex and confusing logging libraries presented in this article. Entirely built on a mixture of complex macros and templates. The study was spent the most time. Even more time is spent on learning "under the hood", perhaps therefore one of the main participants is only one person.
• Lowest performance of all loggers reviewed
• Segmentation fault / access violation when executing code

   char *pStr = nullptr; //…. BOOST_LOG_SEV(lg, trace) << pStr; 

• Accuracy of time marks is not enough, although with such a performance it is not so critical (up to a dozen messages in one time period)
• Repeated gap (up to 54 times) in the performance of the Debug and Release code, it should be noted that in Debug mode, the execution time becomes completely unacceptable (tens of minutes for logging)
• Unicode support does not appear to be well-tested functionality (could not be started for asynchronous logging to a file with sorting and fixed-size FIFO)
• There is no handling of process failures, in the light of the fact that storing data buffers is important even for a synchronous logger — represents a significant risk of losing important data.
• Log record attributes are not trivial - for example, the name of the source function, file, line number. Creating your own attributes is also not a trivial task.
• Tangled compilation with its utilities, but it should be noted that the same compiled binaries are supplied, the problem is common to the whole Boost
• Including a library into your project significantly slows down compilation and linking (even when using precompiled headers)
• All parts of the library code are covered by the generation of exceptions, however, you can set your own interceptor, which reduces inconvenience for people who prefer not to catch exceptions from the logger during each call.

Total