On Monday, 4 January 2016 at 10:58:09 UTC, Jonathan M Davis wrote:
If I understand correctly (based on previous statements by
Dicebot), the problem is that at Sociomantic, they reuse
buffers heavily. So, they basically don't use string much of
anywhere and instead use some combination of char[] and
const(char)[] (so that the array elements can be given new
values without reallocating), and std.experimental.logger -
like a lot of typical D code - uses string, which means that
when they log a message with std.experimental.logger, their
buffer has to be copied into a string, which means that an
allocation occurs, which in their environment is unacceptable.
FileLogger is a Logger that can be used after only one allocation.
new FileLogger;
Everything else (logging, ...) does not require a single
allocation.
If you look at the documentation above [1] you will understand
why.
Building a MultiLogger (Logger of Loggers) that forwards the
calls to the log functions to the contained Loggers without
allocation is also trivial.
Logging into a passed in buffer is also trivial (as long as you
buffer is big enough for the data to log, but that is design
problem).
So, to work for them, they would need std.experimental.logger
to accept something like const(char)[] or an arbitrary ranges
of characters and to not allocate inside of any of its logging
functions. Any requirement to convert to string (be it by the
user of the logger or inside of the logger itself) doesn't work
with their requirements.
as said above, no Logger has to allocate for logging, and no
string has to be created.
An allocation schema was selected however, to make multi
threading work by default.
Creating a user specific Logger that fits the Logger interface
and that uses a static buffer to write the data to is properly
less than 20 lines of code.
I'm not particularly familiar with std.experimental.logger as
it stands, by I would guess that to fit Sociomantic's
requirements, it would need to either manage to log without
actually constructing any array of characters (e.g. by printing
each of its elements in turn without actually putting them
together first), or it would need to reuse a buffer every time
it created the line to log (which would incur the cost of
copying the characters but wouldn't normally have to allocate).
But I don't know how well that fits in with the logger being
hierarchical via classes (which solves other design
requirements) or how close the current implementation is to
that. Certainly, being forced to use classes does prevent the
logger from using some of the typical techniques that we use
(particularly with regards to ranges). So, the logger
definitely presents some challenges that most other Phobos code
doesn't have to deal with. :| Though obviously, you'd be more
aware of that than anyone. :)
- Jonathan M Davis
If you guess of their requirements is correct,
std.experimental.logger fulfills the requirements.
[1]
https://github.com/D-Programming-language/phobos/blob/master/std/experimental/logger/core.d#L812
