Comments on: Scala makes things tidy – logging http://supplesoftware.com/2009/06/29/scala-makes-things-tidy-logging/ George's thoughts on software development Tue, 17 Nov 2009 21:12:44 +0000 hourly 1 http://wordpress.com/ By: supplesoftware http://supplesoftware.com/2009/06/29/scala-makes-things-tidy-logging/#comment-18 supplesoftware Tue, 17 Nov 2009 21:12:44 +0000 http://supplesoftware.com/?p=16#comment-18 Oh, the LoggerFactory.getLogger() you mean? I would imagine the logging framework (aforementioned LoggerFactory) probably does a fair amount of caching and doesn't instantiate a new logger every time. Plus, the kind of objects you would instantiate a lot (model classes?) aren't that fussed about logging. I guess the only way to find out is to profile it... Oh, the LoggerFactory.getLogger() you mean?

I would imagine the logging framework (aforementioned LoggerFactory) probably does a fair amount of caching and doesn’t instantiate a new logger every time. Plus, the kind of objects you would instantiate a lot (model classes?) aren’t that fussed about logging.

I guess the only way to find out is to profile it…

]]> By: Gustavo Hexsel http://supplesoftware.com/2009/06/29/scala-makes-things-tidy-logging/#comment-17 Gustavo Hexsel Mon, 16 Nov 2009 17:29:54 +0000 http://supplesoftware.com/?p=16#comment-17 Here's my BIG quibble with that: the lookup function for the log itself can (probably is) a fairly expensive thing. If you have a ton of object creation, this implementation (even if you use lazy objects) could lead to a huge amount of extra effort, specially if the logging is off (since logging is itself very expensive when it's on, it won't matter as much). The only option (pretty ugly) I've found to avoid these lookups per instantiated object is to create a private object to hold the logger on a package level. You could do that on a per-class case, but it becomes even more verbose. All logging solutions I've seen until now seem to be using this, am I the only one that's raising this question? Here’s my BIG quibble with that: the lookup function for the log itself can (probably is) a fairly expensive thing. If you have a ton of object creation, this implementation (even if you use lazy objects) could lead to a huge amount of extra effort, specially if the logging is off (since logging is itself very expensive when it’s on, it won’t matter as much).

The only option (pretty ugly) I’ve found to avoid these lookups per instantiated object is to create a private object to hold the logger on a package level. You could do that on a per-class case, but it becomes even more verbose.

All logging solutions I’ve seen until now seem to be using this, am I the only one that’s raising this question?

]]>