Voting: std.logger

[Dicebot via Digitalmars-d]

On Tuesday, 2 September 2014 at 13:58:24 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 2 September 2014 at 13:08:02 UTC, Dicebot wrote:
>> While your raise important concerns it doesn't have any 
>> practical application right now and I can't use it in any way 
>> as part of review process. We need details (see the responses 
>> of other voters). Pure theoretical speculations won't help.
>
> Uhm, it isn't theoretical. A low performance string based 
> stdio-logger is not useful in a high performance server where 
> you have short spikes with idle time between the spikes.
>
> A coarse grained logger logs state on the application level and 
> I don't need library support for that since it only happens in 
> a handful of locations that I control myself.
>
> A fine grained logger logs state on the framework/library level 
> and I don't want to use a logger that spends time on turning 
> ints into strings when it is supposed to be handling requests 
> and sits idle a few milliseconds later.
>
> The phobos design lacks a performance oriented focus and si too 
> scripty for a system level langauge.
>
> You need benchmarking from the get go. Performance does not 
> happen later as a QoI issue because performance depends on the 
> model the API implies.
>
> Fine grained logging must be performant.

This is exactly what I call theoretical speculations. Please 
provide specific list like this:

1) some method signature needs to be changed
2) design decision that makes GC allocation unavoidable for 
specific use case
3) example logger implementation that doesn't fit into existing 
API (show how)

If you are going to speak more about abstract performance I am 
going to simply ignore any of your further posts on topic. Sorry 
but there is no other way.