Performance

We're still testing and evaluating fastlog's performance, but we expect it to be very favorable. In comparison with other logging libraries, fastlog does very little work at all. The only overhead applied to each logging function call (regardless of level) is as follows:

• logger-id/category lookup is performed on all the available (added) loggers
• a gen_server cast (or call, if synchronous logging is being used) is dispatched to a logger (gen_server process)

The lookup is probably the most expensive operation that fastlog performs (apart from the actual logging, when a call succeeds in making it to a log handler). This calls supervisor:which_children/1 to find all registered loggers, and proceeds to check each registered logger (process) using lists:filter/1 and a predicate function that uses atom_to_binary and binary:longest_common_prefix. We plan to replace this filtering mechanism with code taken from the lists module by changing logger ids to be strings (instead of atoms), but will not do this until we have a decent baseline from our benchmarks to work against.

The logger (gen_server) processes check if their logging level is enabled by pattern matching, using a context/state record with their current (active) level and matching this against the level being passed to their handle_call/handle_cast clauses. This is likely to be the most efficient way of checking log levels. The logger process(es) will completely ignore any calls to the wrong level (i.e., too high), not even bothering to format the message/arguments at all.