Don't override an externally-set RKLogging class (could be set by another +load before ours).
Just call isEqual: in RKObjectEqualToObject:; I believe the implementations will do essentially the same thing if necessary, which could avoid a series of isKindOfClass: calls.  In my use case this measured out to be marginally faster.
Upgrade to OCMock 2.2.4.  It has some bug fixes, and some enhancements.  Updated some usages of OCMOCK_VALUE, and also updated one unit test which failed (mainly because mock objects return the original class from the -class method now).
Merge pull request #2094 from carllindberg/UpgradeOCMock224

Upgrade to OCMock 2.2.4.
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.
A few further changes, mainly to cut down on the metadatas object being created in the top-level RKMapperOperation by using a custom class instead of creating NSDictionaries each iteration.  This is a little bit faster, especially with many objects at the top level.  Did require changing a private method signature which needed unit test updates.
Merge pull request #2077 from carllindberg/2065-AvoidMergingDictionaries

Speed up metadata implementation
The checking to set unchanged values is actually kind of expensive, especially for the non-CoreData situations (since calling -valueForKey will allocate objects for scalar properties) and it's rearely needed.  To speed things up, add a property on RKMappingOperation which indicates if the destination object came from a data source or not, then use that in the data source methods in order to determine whether to check for changed values.  CoreData will continue to use isTemporaryID for any managed objects, but we can now avoid checking for unchanged values in many cases.  Also, store the result from the data source once in the main method, instead of checking for every attribute.
Change getter method on new property to be "isNewDestinationObject" per PR comments.
RKMapperOperation has more duplicate code from RKMappingOperation than I realized.  So, I did need to expose the new property to that class to be consistent with it.
Change the RKMappingSourceObject superclass from NSProxy to NSObject.  Should function basically the same way, but performance tests in #2065 showed an improvement for some unknown reason (test application never invoked forwardInvocation:, so it has nothing to do with that).  Implemented some NSObject protocol methods to make sure they get forwarded to the object, and implemented -forwardingTargetForSelector: which is a much faster forwarding mechanism in case it does get used.  Also must implement rk_classForPropertyAtKeyPath: for unit tests to pass since that was no longer being forwarded.  Changed self.object references to _object to avoid additional method call; may have squeezed a tiny bit more performance with that.
Given some further tests, avoiding the ivar access is probably more important than avoiding ObjC calls, but local variables help either wya.  Added more local variables to RKMappingOperation.  Relatively small speedup, but it's there.
Merge pull request #2080 from carllindberg/2065-FasterShouldSetUnchanged

Always set unchanged values for newly-instantiated non-CoreData objects
Merge pull request #2085 from carllindberg/2065-RKMappingSourceObjectSuperclass

Change the RKMappingSourceObject superclass to NSObject.
Merge pull request #2090 from carllindberg/FixRKLoggingInitialization

Fix RKLogging initialization
Merge pull request #2091 from carllindberg/2065-RKObjectIsEqualToObject

Tiny speedup in RKObjectIsEqualToObject
Merge pull request #2092 from carllindberg/2065-MappingOperationLocalVars

Use local variables in RKMappingOperation to avoid multiple calls to methods
Add API to RKObjectMappingMatcher to be able to supply a dictionary of values to object mappings, so a value in a source map can do a single lookup to find the corresponding RKObjectMapping, instead of doing an iterative search through a number of individual RKObjectMappingMatchers.  To support the -objectMappings method of RKDynamicMapping, this required adding a new method to RKObjectMappingMatcher which can supply an array of possible RKObjectMappings to be returned.  Additionally, made that method return a constant array instead of creating a new one every call, as it gets called during the mapping process, which should further help performance when using dynamic mappings.  Also added an API so that a list of RKObjectMappings can be passed in with an evaluation block, again to better support the -objectMappings method.
Update code to add a block matcher rather than change RKDynamicMapping directly, which should be more flexible anyways.