> On Feb 26, 2017, at 2:34 PM, Daryle Walker <dary...@mac.com> wrote:
> 
> If I take a "subdata" of a memory-mapped (NS)Data, does it stay mapped (i.e. 
> use a range and reference)? Or does a full copy get made? I'm thinking of 
> making a parser be a sub-parser too, and this would make the difference 
> between scanning the next megabyte or the rest-of-file (even if it's 
> gigabytes).

Whew … that’s definitely an implementation detail, and the sort of thing that 
I’d imagine can change from one OS version to another. There are cases like 
yours where this behavior can be hugely valuable, and others where it can be a 
big performance problem (not so much with mapped data,  but definitely with 
heap allocations.) Even if you did some experiments today and found that it 
works the way you want, there’s no guarantee it’ll keep working that way.

I recommend using a custom data structure instead of relying on NSData 
behavior. In my C++ code I’ve long relied on a simple struct I call “slice”: 
It’s just a {void*, size_t} representing an _unowned_ reference to a range of 
memory. It’s incredibly useful. You do have to be careful with memory 
management, since obviously something has to own the memory and you don’t want 
a slice to outlive the owner, but slices are very very lightweight and easy to 
pass around and subdivide.

You can easily create this on your own, but if you use C++ there are all kinds 
of bells and whistles you can add to it for convenience (including subclasses 
that do own memory the way NSData does.) The current version of my 
implementation lives here:
        https://github.com/couchbaselabs/fleece/blob/master/Fleece/slice.hh

—Jens
_______________________________________________

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

Reply via email to