• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: copying an object instance using NSCopyMemoryPages
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Follow-Ups:
    • Re: copying an object instance using NSCopyMemoryPages
      • From: Matthew Johnson <email@hidden>
References: 
 >copying an object instance using NSCopyMemoryPages (From: Matthew Johnson <email@hidden>)

  • Prev by Date: Re: 'class' in .h file
  • Next by Date: Re: SearchKit vs. Lucene
  • Previous by thread: copying an object instance using NSCopyMemoryPages
  • Next by thread: Re: copying an object instance using NSCopyMemoryPages
  • Index(es):
    • Date
    • Thread