Re: NSMutableData capacity
Re: NSMutableData capacity
- Subject: Re: NSMutableData capacity
- From: Andreas Grosam <email@hidden>
- Date: Thu, 24 May 2012 09:43:38 +0200
Thank you for your replies. I appreciate your comments.
Maybe you are interested in the background, and way I'm asking this. In fact, as some of you suspected, the reason for asking has to do with performance.
The NSMutable data shall serve as an internal buffer of some "Streambuffer" class which has roughly this interface:
@interface MutableDataStreambuffer : NSObject <StreambufferProtocol>
- (id) init;
- (id) initWithData:(NSData*)data;
// StreambufferProtocol
- (void) writeBytes:(const void*)buffer length:(NSUInteger)length;
// MutableDataStreambuffer methods
- (NSData*) data;
@end
The method data returns a *copy* of the internal buffer.
-initWithData initializes the internal buffer through copying the content of param data to the internal buffer.
Strictly, the internal buffer does not need to be a NSMutableData. But sometimes, in order to avoid copying, in private implementations, I would prefer to have a NSMutableData object, thus:
@interface MutableDataStreambuffer (Private)
- (NSMutableData*) buffer;
@end
When using a NSMutableData as the internal buffer, and in order to maintain good performance, I use interior pointers to the contents of the object, namely _begin, _p and _endcap;
In order to rely on the validity of the pointers, I use
-increaseLengthBy: and -setLength:
and manage the *actual* size of the buffer manually. This is slightly suboptimal, though.
While I experienced, that this approach is much faster than appending bytes using NSMutableData methods, the above implementation could be still better when having something like a -capacity method for a NSMutableData object which is the size of the raw memory buffer of the underlaying allocator, and not some potential "max size" or "hint".
I understand, that capacity may not make sense in certain concrete implementations of NSMutableData, though.
Regards, and thanks for your tips and comments!
Andreas
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden