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.
