Add a datasource method to indicate whether RKMappingInfo is necessary; it is only needed for CoreData presently, and is a performance hit otherwise.
Add documentation for the new data source method.
Change internal property name to collectsMappingInfo per PR comment
The RKObjectMapping -classForKeyPath: gets called a lot; avoiding the creation of a temporary NSArray for simple keys (the usual case) makes a measurable speed difference.
Whoops, need to deal with a nil key.
Add caching for different property mapping types, both in RKObjectMapping, and RKMappingOperation.  Determining simple vs keyPath mappings was somewhat of a hotspot, so caching them in RKMappingOperation helps a bit.  However, these will be identical to the versions in RKObjectMapping if there is no substitution (the most common case), so if we cache the properties there, then we can just re-use the same array for the operation without creating local copies at all, which is a substantial speedup.  Similarly, caching the attribute vs relationship mappings when added to the RKObjectMapping is also a significant speedup during mapping since these don't have to be recalculated for every object being mapped.  Lastly, changed the substitution values to be an individual key and value internally, instead of a dictionary.  This avoids the need to use "allKeys" to obtain the key (and allValues to get the value), which avoids more NSArray instances being created locally.
Updates per PR comments.  Change RKObjectMapping property to keyAttributeMappings, and initialize the properties in -init.  Change internal RKMappingOperation method to cacheMappingsIfNeeded.
Making a few tweaks to RKMappingOperation applyRelationshipMappings.  First, there is a temporary array created which ends up only being used for its count, so changed to an NSUInteger.  Just a small speedup, but it's there.  In another section, the code was calling valueForKeyPath "mapping.propertyMappings.sourceKeyPath" on an RKRelationshipMapping, which if it happens to be an RKDynamicMapping, I think would fail.  Code immediately above has already determined the RKObjectMapping, so it's easier to just call the method directly, and iterate using the RKPropertyMappings directly, which avoids another temporary array allocation.  Also avoided a double call to RKObjectIsCollection though that is a minimal speedup.
Small speedups in RKPropertyInspector.  Regular objects are faster than dictionaries, so for the actual property information using a simple method call instead of -objectForKey: has a small but measurable speedup.  Deprecated the previous key constants, though implemented methods such that if used as a dictionary it should continue to work in most cases.
Updates per PR comments.  Remove deprecation path; this is a slightly incompatible change now, though RestKit usage is fine.  Change to use dot syntax for properties, and use inspector local variable.  Also speed up the NSManagedObject override of rk_classForPropertyAtKeyPath: which I had missed before.
Merge pull request #2082 from carllindberg/2065-ApplyRelationshipMappings

Few changes to applyRelationshipMappings
Cache the propertyMappings in dictionary form by both the destination and source keys, which allows for faster lookup during mapping.  Also, change a couple of CoreData related calls to use the fast-lookup method rather than a method which constructs an entire dictionary to then just look it up by key.  I left the accessor methods as "copy" rather then having immutable dictionaries because those methods are no longer called from the core mapping code (or anywhere else, for that matter).
Merge pull request #2083 from carllindberg/2065-RKPropertyInspector

Small speedups in RKPropertyInspector
Merge pull request #2081 from carllindberg/2065-CachePropertyMappings

Add caching for different property mapping types
Merge pull request #2070 from carllindberg/2065-ObjectMappingClassForPath

The RKObjectMapping -classForKeyPath: gets called a lot; avoiding the cr...
Merge pull request #2078 from carllindberg/2065-CollectMappingInfo

Avoid collection of RKMappingInfo when not using CoreData
Instead of merging dictionaries, keep a list of separate metadata dictionaries and implement valueForKeyPath: to iterate through them.  This is a bit more substantial change, and one situation may still be a bit inefficient -- when creating a parentObject for a deep hierarchy, we need to create some standin objects which implement valueForKey: the same way, rather than intercepting at the RKMappingSourceObject class.  Not sure if there is a way around that.
Further speed changes; the creation of the metadata dictionaries is fairly expensive; a specialized object can be faster.  Also, it allows us to create just one and re-use the instance whiel iterating over a to-many relationship.  Secondly, the metadata used for a to-one relationship is constant, so can be a static instance created just once.  Refactor some of the code used in the previous commit and document new public methods.