1 files changed, 31 insertions, 0 deletions
diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md
index 77a2dd4b18..50ee934b87 100644
--- a/guides/source/debugging_rails_applications.md
+++ b/guides/source/debugging_rails_applications.md
@@ -209,6 +209,37 @@ logger.tagged("BCX", "Jason") { logger.info "Stuff" }                   # Logs "
 logger.tagged("BCX") { logger.tagged("Jason") { logger.info "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:
+
+```ruby
+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:
+
+```ruby
+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
 ---------------------------------