Multiple memory allocations and frees are the bane of performance-oriented code. STL is particularly naughty in this regard.

To that end, logog attempts to do as few allocations as possible at run-time. Message objects are allocated exactly once, when a message macro is run for the first time. Publisher-subscriber negotiation occurs at this time as well, which is when the pub-sub lists in the Filter objects get updated. This process happens only once per message, regardless of the number of times the message is invoked. Therefore, messages that are never executed never allocate any memory, and the memory-allocation penalty for a message is incurred exactly once, the first time the message is transmitted.

A platform-specific vsprintf() type function is used to convert the varargs in a message into a final destination string. I looked at this problem for quite a while, and it seems that this method provides the best performance guarantees without relying on a large external library, such as Boost, or increasing the code size significantly. A template-based approach for running vsprintf type functions would theoretically be faster than calling vsprintf(); however, this would require the inclusion of a significant amount of template-based code to handle all the possible situations that vsprintf() must deal with. This would likely double the existing code size; so I erred on the size of keeping logog smaller and more self-contained.

If, after all that, you want to replace vsprintf() for your platform, it is called in only one place in the logog source code (in String.cpp).

Because logog spends so much time passing strings around, logog provides a custom string class that internally represents strings as fixed buffers. This helps reduce the repeated allocations and frees that std::string is notorious for.

Because most logging outputs can be slow, logog provides a LogBuffer class to help with Deferring logging output .