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)?
