SLF4s and @elidable

[Sciss]

hi,

does the following make sense?

@elidable(CONFIG) def logConfig( what: String ) { log.info( what )}

def test : Int = {
logConfig( "testin one two" )
666
}

where log is taken from SLF4s.

that is to say, i understand that in SLF4s logging is suppressed according to log-level set. but what i'd like to have is to not even invoke logConfig at all if i decide so with an elide-below level.

as i see it, log.info would call

def info(msg: => String) {
if (slf4jLogger.isInfoEnabled) slf4jLogger.info(msg)
}

so without @elidable i'd have

def test : Int = {
if (slf4jLogger.isInfoEnabled) slf4jLogger.info("testin one two")
666
}

whereas with elidable i would really get

def test : Int = {
666
}

if i wanted, right?

thanks, -sciss-

[Sciss]

since no one answered -- my conclusion is it does make sense for performance critical stuff that needs debug logging.

best, -sciss-

[Naftoli Gugenheim]

Don't forget call-by-name. I think most scala logging libraries take their message as a =>String. That largely accomplishes what you want, I think.

[Sciss]

i was thinking about this, but came to the conclusion that it doesn't make sense here.

if i have

@elidable def log( what: String ) { println( "LOG: " + what )}

and

def test( i: Int ) = {
log( "found " + i )
i + i
}

when i let scalac eliminate the elidable stuff, the call log( ... ) in test is also removed (as far as i understand, and from what the step debugger tells me), so adding a by-name argument is redundant here, and probably also not preferable performance-wise.

right?

best, -sciss-

[Naftoli Gugenheim]

True, but if your log method only evaluates the message if the log level is past the threshold, then eliding is less necessary.

Anyway, do you set log levels at compile time or run time?

[Sciss]

in this particular case, the logging was used for debugging, and i just wanted to switch it on and off. true, if i wanted granularity with log-levels, i'd use a runtime if( ... ) filter and by-name arguments.

best, -sciss-

[Simon Ochsenreither]

Doesn't that mean that every log message basically creates a new class file?

[rkuhn]

Yes, which is why I have gone a different route in Akka, see https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/event/Logging.scala#L452

[Simon Ochsenreither]

I fear that all these anonymous-class-avoidance strategies will be obsolete with Java 8 again ... quite some API churn, imho.