Browse files

Merge pull request #11534 from gaurish/log

Add logging performance [ci skip]
  • Loading branch information...
drogus committed Jul 21, 2013
2 parents a836db0 + b48bb74 commit 2c1ddd82e68d24e793a7e80076459455aa8fb5d6
Showing with 31 additions and 0 deletions.
  1. +31 −0 guides/source/
@@ -209,6 +209,37 @@ logger.tagged("BCX", "Jason") { "Stuff" } # Logs "
logger.tagged("BCX") { logger.tagged("Jason") { "Stuff" } } # Logs "[BCX] [Jason] Stuff"
+### Impact of Logs on Performance
+Logging will always have a small impact on performance of your rails app,
+ particularly when logging to disk.However, there are a few subtleties:
+Using the `:debug` level will have a greater performance penalty than `:fatal`,
+ as a far greater number of strings are being evaluated and written to the
+ log output (e.g. disk).
+Another potential pitfall is that if you have many calls to `Logger` like this
+ in your code:
+logger.debug "Person attributes hash: #{@person.attributes.inspect}"
+In the above example, There will be a performance impact even if the allowed
+output level doesn't include debug. The reason is that Ruby has to evaluate
+these strings, which includes instantiating the somewhat heavy `String` object
+and interpolating the variables, and which takes time.
+Therefore, it's recommended to pass blocks to the logger methods, as these are
+only evaluated if the output level is the same or included in the allowed level
+(i.e. lazy loading). The same code rewritten would be:
+logger.debug {"Person attibutes hash: #{@person.attributes.inspect}"}
+The contents of the block, and therefore the string interpolation, is only
+evaluated if debug is enabled. This performance savings is only really
+noticeable with large amounts of logging, but it's a good practice to employ.
Debugging with the `debugger` gem

0 comments on commit 2c1ddd8

Please sign in to comment.