SLF4s and @elidable

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

best, -sciss-

On 30 Nov 2011, at 16:50, Sciss wrote:

> 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-
>

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.

On Fri, Dec 2, 2011 at 10:45 AM, Sciss <contact@sciss.de> wrote:

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

best, -sciss-

On 30 Nov 2011, at 16:50, Sciss wrote:

> 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-
>

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-

On 5 Dec 2011, at 07:18, Naftoli Gugenheim wrote:

> 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.
>
>
> On Fri, Dec 2, 2011 at 10:45 AM, Sciss wrote:
> since no one answered -- my conclusion is it does make sense for performance critical stuff that needs debug logging.
>
> best, -sciss-
>
> On 30 Nov 2011, at 16:50, Sciss wrote:
>
> > 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-
> >
>
>

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?

On Mon, Dec 5, 2011 at 2:20 AM, Sciss <contact@sciss.de> wrote:

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-



On 5 Dec 2011, at 07:18, Naftoli Gugenheim wrote:

> 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.
>
>
> On Fri, Dec 2, 2011 at 10:45 AM, Sciss <contact@sciss.de> wrote:
> since no one answered -- my conclusion is it does make sense for performance critical stuff that needs debug logging.
>
> best, -sciss-
>
> On 30 Nov 2011, at 16:50, Sciss wrote:
>
> > 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-
> >
>
>

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-

On 5 Dec 2011, at 07:37, Naftoli Gugenheim wrote:

> 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?
>
>
> On Mon, Dec 5, 2011 at 2:20 AM, Sciss wrote:
> 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-
>
>
>
> On 5 Dec 2011, at 07:18, Naftoli Gugenheim wrote:
>
> > 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.
> >
> >
> > On Fri, Dec 2, 2011 at 10:45 AM, Sciss wrote:
> > since no one answered -- my conclusion is it does make sense for performance critical stuff that needs debug logging.
> >
> > best, -sciss-
> >
> > On 30 Nov 2011, at 16:50, Sciss wrote:
> >
> > > 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-
> > >
> >
> >
>
>

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

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/akk...

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