-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LogFilter overhead #899
Comments
hello @Dennis4b, actually initially i was thinking to do final class ZioLoggerRuntime(runtime: Runtime[Any], filter: (String, LogLevel) => Boolean) extends LoggerRuntime
object Slf4jBridge {
def init(filter: LogFilter[Any]): ZLayer[Any, Nothing, Unit]
def init(filter: (String, LogLevel) => Boolean): ZLayer[Any, Nothing, Unit]
} but at the end i did it like it is now, to have it less complicated ... so, probably to do it like ^^^, could make it more performant in your case |
Thank you for your response! The main cost is in constructing the While I don't mind contributing or testing possible solutions, so that I don't need to maintain a private fork to use with Apache Fop, I don't know what the design goals for zio-logging are and what kind of solutions, if any, would be considered. It is of course a very extreme case to log so many messages, but it happens and I have to deal with it somehow. At first glance, because of all the default constants, it seems the Your example: This is not ZIO library style but as an example that works for me:
|
yes, i see it in same way so probably then, rather then have specific implementation of filters for slf4j-bridge it could be better to change underlying implementation, in way that trace and annotations for name are created just once |
Thank you for looking at this so quickly. So, I don't use the bridge v1, but, if I simulate the same changes in v2, that is:
then this solves the issue and performance is similar to the short circuit filter, so I think this would be a good solution. |
hello @Dennis4b , i added also impl for slf4j2-bridge |
Hi @justcoon, if I use your repository with branch |
hello @Dennis4b , i released new version https://github.com/zio/zio-logging/releases/tag/v2.4.0, which should contains those changes |
I am aware of #810 which addressed initial performance concerns by implementing
isDebugEnabled(..)
and friends.I am using zio-logging as an slf4j2 bridge, in order to capture all output related to particular requests or tasks, also from third party components.
In one project I use Apache Fop, which since its latest version 2.10 uses Apache Commons logger, which is an unconfigurable (in terms of filtering) log forwarder, to, in this case, zio-logging.
As far as logging goes it works perfectly.
However, I don't know if there is any amplification going on, but inside
slf4j2-bridge/src/main/scala/zio/logging/slf4j/bridge/ZioLoggerRuntime.scala
the methodisEnabled(name: String, level: Level)
gets called with loglevel Debug over 3 million times for a single run of a single tiny document. I agree that this is probably excessive, but it's not something I can control.Timings for comparison:
~300ms
per documentSlf4jBridge.initialize
and default filtering in the loggers (>= Info
) -> 5-10 seconds per documentSlf4jBridge.init(LogFilter.logLevel(_ > LogLevel.Debug))
->~900ms
per document~300ms
per documentThe current design of
LogFilter
requires collecting and passing all the parameters, even though a simple LogLevel filter is just going to look at one of them. When replaced by a short circuit check the overhead disappears and we go from900ms
down to300ms
for a single document run.The following example modification demonstrates the idea- but note that the type test can not be checked at runtime so it is not a proper solution and would probably cause issues if another LogFilter is used in its case.
With this code I have proper logging of everything
>= Info
at the original300ms
duration.The text was updated successfully, but these errors were encountered: