stantiate a
>> logger, you have to fetch at least the log level definition from some
>> configuration source, and this can never be fast. At least not that
>> we're talking about nanoseconds here.
>>
>> All logging implementations I know of (and all that make sense) are
>> highly optimized on log throughput; this can only be achieved by
>> preprocessing during initialization, why this is slow. But that doesn't
>> matter, because, as said, you should anyway create logger instances
>> beforehand.
>>
>> Sorry for the rant, but I really don't see the use case here.
>
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
out 11'000 nanoseconds,
reducing throughput by a factor of 24.
While logging 2'000'000 messages per second is not a goal, reducing the
cost of logging as much as possible, is a worthwhile goal. At present
time, retrieving caller data still has a significant effect on logging
perfo
c/java.logging/share/classes/java/util/logging/LogRecord.java#L754
>
> Jason
>
>
> From: core-libs-dev on behalf of Ceki
> Gülcü
> Sent: Wednesday, April 6, 2022 4:26 PM
> To: core-libs-dev
> Subject: Re: fast way to
make sense? How difficult would it be to add such a method?
--
Ceki Gülcü
On 4/6/2022 5:52 PM, Remi Forax wrote:
> - Original Message -
>> From: "Ceki Gülcü"
>> To: "core-libs-dev"
>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>> Subject: f
CPU time. Do you think the JDK could cater
for this use case?
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
