Skip to content
Browse files

Add logging performance [ci skip]

  • Loading branch information...
1 parent 34b8953 commit b48bb74ef8a8bc9539d5b9c7d5fe202f37e2e99c @gaurish gaurish committed Jul 21, 2013
Showing with 31 additions and 0 deletions.
  1. +31 −0 guides/source/
31 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 b48bb74

Please sign in to comment.
Something went wrong with that request. Please try again.