Correct docs for after_find and after_initialize

activerecord/lib/active_record/callbacks.rb

@@ -25,7 +25,11 @@ module ActiveRecord
   # Check out <tt>ActiveRecord::Transactions</tt> for more details about <tt>after_commit</tt> and
   # <tt>after_rollback</tt>.
   #
-  # That's a total of ten callbacks, which gives you immense power to react and prepare for each state in the
+  # Lastly an <tt>after_find</tt> and <tt>after_initialize</tt> callback is triggered for each object that 
+  # is found and instantiated by a finder, with <tt>after_initialize</tt> being triggered after new objects
+  # are instantiated as well.
+  #
+  # That's a total of twelve callbacks, which gives you immense power to react and prepare for each state in the
   # Active Record life cycle. The sequence for calling <tt>Base#save</tt> for an existing record is similar,
   # except that each <tt>_on_create</tt> callback is replaced by the corresponding <tt>_on_update</tt> callback.
   #
@@ -185,14 +189,6 @@ module ActiveRecord
   #                    'puts "Evaluated after parents are destroyed"'
   #   end
   #
-  # == The +after_find+ and +after_initialize+ exceptions
-  #
-  # Because +after_find+ and +after_initialize+ are called for each object found and instantiated by a finder,
-  # such as <tt>Base.find(:all)</tt>, we've had to implement a simple performance constraint (50% more speed
-  # on a simple test case). Unlike all the other callbacks, +after_find+ and +after_initialize+ will only be
-  # run if an explicit implementation is defined (<tt>def after_find</tt>). In that case, all of the
-  # callback types will be called.
-  #
   # == <tt>before_validation*</tt> returning statements
   #
   # If the returning value of a +before_validation+ callback can be evaluated to +false+, the process will be