On Feb 13, 2013, at 8:07 PM, James Maxwell wrote: > I've run into a situation where I really need a deep copy of an object. I've > implemented this using Apple's recommended approach with > NSKeyedArchiver/Unarchiver, and it's nice, simple, and functional. But it's > also pretty darn slow -- as in a clear, subjectively apparent performance hit. > Has anybody had to find a way around this, and if so, what did you do? Or if > anybody just has a nice, creative thought about another way of doing it, I'd > love to hear about it. > > The object(s) being copied are custom classes, and there's a chance I may be > able to get away with copying only certain properties (i.e., rather than > archiving the entire graph from the root object), so I'll look into making a > "deepCopy" method that's more selective. But I'd appreciate any thoughts in > the meantime.
I'd expect a -deepCopy method to be substantially faster even if it weren't any more selective about which properties get copied. The main difficulty is when your object graph may have cycles or diamonds. Archiving will store each object exactly once and all references to it will refer to that; then, on unarchiving, the references will be restored properly. A naive deep copy will cause an object which is referenced from two points in the object graph to end up as two separate objects in the new graph. And cycles can cause infinite recursion. Your question prompted me to try to design an analog of NSKeyedArchiver, NSCode, and NSCoding that would generate the new object graph on the fly as it went instead of producing a data object. The idea is that the copier (the analog of the archiver/coder) would know which objects had already been copied and so would avoid over-duplicating them in the new graph. However, that ends up being hard because each object has to copy its related object before it's complete enough to be registered with the copier. So, it isn't successful in avoiding the potential for infinite recursion. An obvious question is: have you analyzed the NSKeyedArchiver approach to understand why it's slow? Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
