This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-04
Channels
- # announcements (7)
- # babashka (32)
- # beginners (106)
- # bristol-clojurians (10)
- # cider (6)
- # clj-kondo (5)
- # cljdoc (10)
- # clojure (110)
- # clojure-australia (10)
- # clojure-dev (6)
- # clojure-europe (12)
- # clojure-nl (2)
- # clojure-norway (16)
- # clojure-spec (9)
- # clojure-uk (59)
- # clojurescript (105)
- # community-development (2)
- # conjure (46)
- # cursive (12)
- # data-science (1)
- # datalog (26)
- # datomic (37)
- # docker (4)
- # emacs (10)
- # events (1)
- # fulcro (8)
- # graalvm (2)
- # jobs (1)
- # jobs-discuss (1)
- # malli (24)
- # meander (13)
- # off-topic (52)
- # pathom (4)
- # polylith (17)
- # proletarian (4)
- # react (1)
- # rewrite-clj (4)
- # shadow-cljs (56)
- # sql (21)
- # xtdb (14)
Hello. Question about clojure.tools.logging.impl
.
In get-logger
implementation we call (str logger-ns)
(reify LoggerFactory
(name [_#]
"org.slf4j")
(get-logger [_# logger-ns#]
(org.slf4j.LoggerFactory/getLogger ^String (str logger-ns#))))
This str
is called every time from enabled?
.
As result disabled levels like (log/trace ...)
utilise ~30 ms just in testing for enabled?
.
Can this code be improved so that disabled log levels cost as little as possible?Well, probably I'm wrong and slow part is org.slf4j.LoggerFactory/getLogger
is the slowest part...
It would be great to avoid repetitive computations for every log statement in single namespace...
@serioga Since the Clojure code in tools.logging
is just delegating to one of a number of Java libraries, and it is inside those Java libraries that the decision about disabled log levels is done, based on their configuration, I'm not sure how much "delegation overhead" you're going to be able to get rid of. I'd say that if you really care about logging performance and the overhead of disabled log levels, you should either not put logging calls in performance-critical code or not use tools.logging
and do Java interop directly, or both.
@seancorfield fairly :-)