Re: copying an object instance using NSCopyMemoryPages
Re: copying an object instance using NSCopyMemoryPages
- Subject: Re: copying an object instance using NSCopyMemoryPages
- From: Dietmar Planitzer <email@hidden>
- Date: Sat, 22 Nov 2003 12:26:20 +0100
On Nov 21, 2003, at 9:35 PM, Matthew Johnson wrote:
I would like to make a category on NSArray that allows occassional
changes to the array with no performance impact except when the change
is made. This would be very useful when changes to the array happen,
but are extremely rare. The idea is that it would use
forwardInvocation: to make a mutable copy, invoke the change, and then
get a static copy and replace the instance with the new static array.
I am including the code that I have so far at the end of this message.
What I am wondering is will this work and are there any caveats I
should look out for?
The chances that your code will work are quite limited because of this:
<snip>
int retainCount = [self retainCount];
[self dealloc];
NSCopyMemoryPages(newSelf, self, myClass->instance_size);
int i;
for (i = 1; i < (retainCount); i++) {
[self retain];
}
<snip>
The code above is making assumptions about how NSArray is internally
organized. This, however, is very bad and dangerous because even if the
assumptions are valid for the current system version, they may already
break with the next minor system update (i.e. 10.3.2).
So for example, there is nothing that guarantees that an NSArray would
consist of just one single memory block. It could be that the memory
block pointed to by newSelf/self contains just maintenance information
like the number of objects in the array and that the actual array
contents is stored in another memory block.
In fact NSArray like some other classes, most notably NSDictionary and
NSString, are technically quite complicated beasts because they are not
only class clusters but also toll-free bridged with their CF
equivalents. Consequently you can not know what the exact layout of an
NSArray instance is at runtime because Foundation can choose among a
number of different internal classes when it creates an instance - each
with their own specialized layout.
A note about NSCopyMemoryPages(): Copying data with this call only
makes sense if your data consumes at least 2 pages upward. Otherwise
the time that it takes for the kernel to set up the COW mappings plus
the time that it takes to handle the COW pages faults is just too
large. You should use good old memcpy() for smaller data areas.
Regards,
Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.