Voting: std.logger

[via Digitalmars-d]

On Wednesday, 3 September 2014 at 11:39:59 UTC, Kevin Lamonte 
wrote:
> I've written my own ideas about logging vs tracing over at 
> https://github.com/klamonte/log4d/docs/philosophy.md

Nice writeup! It is kind of interesting that there are so many 
different takes on a mundane task such as logging, monitoring, 
debug-tracing etc. Reminds me of reflections on how many types of 
NULL you need to cover all the different semantics that NULL can 
express (was it 5 or 6?).

> It sounds like what you would like is a trace function that 
> doesn't feature a format string at all, but formatting would 
> instead be applied at I/O time by a Logger subclass.

Yes, either that or no formatting at all. If all formatting 
strings are literals and resolve at compile time then you can 
extract them from the source and create a big compile time map 
that convert them into numeric values at compile time and convert 
the types into numeric values as well. If the API supports full 
compile time reflection that should be a possibility.

High performance logging should just be a series of MOV 
instructions or SSE equivalents that completes in ~8-40 cycles 
for a circular buffer with 2^N size. With increasing availability 
of memory on cloud servers this becomes more and more attractive 
IMO (you can log a lot in 50MB)

It important is that you exploit the fact that the values are 
already in registers because you usually log values that have 
recently been computed and that you spend a minimal amount of 
execution time on registering them, perhaps even writing directly 
to full memory cache lines to avoid cache pollution (using 
special SSE commands).

If you accept slightly out of sync logging then you can have 
thread local buffers and on x86 use the command RDTSC which gives 
you a (good enough) timer value so you can merge the buffers from 
threads later. It takes roughly 20-30 cycles which I presume is 
better than CAS instructions, or you can just write directly to a 
global counter without CAS and accept that it jitters?

I personally don't care about enter/exit so much. I care about:

1. tracking the state of the system configuration at the point of 
failure
2. the paths of execution before the incident
3. the events that led up to it (in order to reproduce the 
failure).

> This could also be split into traceFnEnter, traceFnExitSuccess, 
> and traceFnExitFailure with LogEntry.args set to indicate which 
> one (">", "<", "!<" for example) and a mixin provided so that 
> client code could get it all in a one-liner.

Sounds like a candidate for an attribute, just prefix a function 
or function call with @trace(level)?