On Tuesday, 2 September 2014 at 14:53:17 UTC, Dicebot wrote:
If you are going to speak more about abstract performance I am
going to simply ignore any of your further posts on topic.
I am not abstract. These are very concrete requirements:
1. You have to be able to determine types and formatting at
compile time otherwise you cannot do binary logging.
2. You have to be able to determine types and formatting at
compile time otherwise you cannot minimize the probability of
introducing run-time errors by turning on full logging.
This is very important use scenarios:
* Performant fine grained logging (as close to zero overhead as
you get) in libraries and frameworks is essential for fixing
cloud-based servers where you typically cannot use regular
strategies. I don't control frameworks, so it is important that
they use standard lib logging.
* Performant fine grained logging (as close to zero overhead as
you get) in client side frameworks is essential for fixing online
game clients that runs on heterogenous hardware since you don't
get to run a debugger on all configurations.
I don't know enough about what the limitations for advanced
compile time reflection is, but it has been claimed in this
thread that the current design does not make it possible to
establish this at compile time.
Then I have to conclude that the current design cannot be safe
enough or performant enough to be useful in libraries and
frameworks and give D an advantage in the server-market...
Risks:
1. If D libraries and frameworks starts using and
under-performing logger because it is the official D logger
library, then you cannot ship products with fine grained logging
based on these framworks. This is a lost opportunity.
2. If phobos includes under-performing libraries then you risk
having a new split and have two standard libraries and/or two
incompatible logging frameworks.
