I suggest reading in the entire file into your NSData with
initWithContentsOfFile: if there's a significant chance of file
modification. I know this sounds like a huge memory usage but this
way you can know your data is static and the system is designed to
handle high memory usage programs. If there's some pages of your data
you haven't touched in a while the system will swap those out and use
the physical pages for something that needs them.
When making substrings from the data you can save making redundant
copies using initWithBytesNoCopy:length:encoding:freeWhenDone: for
string objects that only reference the characters from the data. They
depend on the NSData object so it needs to be valid for these strings
to work. If you want permanent copies of some substrings you can use
initWithString: to make them; I'm not sure if using copy will just
make another object only referencing the data like the original. If
you make the substrings with any of NSString's substring* methods, the
returned strings will be independent and won't become invalid if the
NSData or base string are released.
On May 13, 2008, at 1:55 PM, Daniel Vollmer wrote:
On May 13, 2008, at 17:00, Jens Alfke wrote:
On 12 May '08, at 11:38 PM, Daniel Vollmer wrote:
It sounds like you're creating a single NSString containing the
entire contents of the file, then?
Yes. Is that something I shouldn't do? I mean, I feel a tiny bit
silly creating such huge strings but I didn't find a nice
alternative (e.g. like the Ruby for each line iterators on file
objects).
Yes. Even if the NSString is still using the NSData's contents for
its buffer, it retained them, so releasing the NSData won't make it
go away until the string is done with it.
But now that means that the strings are "endangered" from in-place
file modification for the lifetime of my objects created during
parsing, not just the initial parsing itself, correct?
Also, it feels a bit silly to have a retain on the 20MB NSData
object while I still hold references to about 5KB of string bytes
from various places in the file. Usually all this "behind-the-
scenes" storage retaining doesn't matter much, but I'd quite like to
make sure I drop most of the 20MB once I'm done parsing. This
question of course also applies if I'm not mapping the file and
creating a String from it directly
FWIW, my current iteration looks like this (String being the big
20MB one);
NSUInteger length = [String length];
NSUInteger paraStart = 0, paraEnd = 0, contentsEnd = 0;
while (paraEnd < length)
{
[String getParagraphStart:¶Start end:¶End
contentsEnd:&contentsEnd forRange:NSMakeRange(paraEnd, 0)];
line = [String substringWithRange:NSMakeRange(paraStart,
contentsEnd - paraStart)];
// do lots of menial parsing of line
}
If I leave the mmaped reading in, it sounds like a sensible idea to
check whether the file is on the same drive as the app. So thanks
for that suggestion.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
