Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- Subject: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- From: Michael Ash <email@hidden>
- Date: Tue, 27 Jan 2009 22:38:02 -0500
On Tue, Jan 27, 2009 at 6:43 PM, Jean-Daniel Dupas
<email@hidden> wrote:
>
> Le 27 janv. 09 à 23:52, Michael Ash a écrit :
>
>> On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
>> <email@hidden> wrote:
>>>>
>>>> Will thanks for the heads up, for my purposes this time around, the
>>>> input stream will be coming in off the file system, but I did not want
>>>> to load the whole thing into an NSData object.
>>>
>>> Ah! Well, your approach will work, but if your file is less than 4GB I
>>> highly recommend something like:
>>>
>>> NSData *fileData = [NSData dataWithContentsOfFile:path
>>> options:NSUncachedRead error:&error];
>>>
>>> This is NOT implemented by Apple in a naïve way - eg, it doesn't read the
>>> whole dang file and blat it into memory. Instead, it reads blocks
>>> on-demand,
>>> in a most efficient manner.
>>
>> Actually it does, as can be trivially verified by sticking it in a
>> quickie test program, pointing it at a very large file, and watching
>> it grind away for several seconds while its RPRVT goes up and up.
>>
>> Perhaps you meant NSMappedRead here?
>>
>> And note that "less than 4GB" really means more like "less than 2-3GB"
>> due to address space fragmentation, and even then you can only have
>> ONE of the things in memory at a time if you do that, and aren't in
>> 64-bit land. More realistically speaking, you should probably not use
>> NSData to read entire files (mapped or otherwise) once you can
>> reasonably expect those files to surpass 500MB or so, and even when
>> you're near the limit you need to apply a great deal of thought when
>> doing so to make sure that the user couldn't possibly, say, cause your
>> app to open several of them simultaneously.
>>
>> If you are fortunate enough to be able to build 64-bit-only then these
>> problems largely go out the window, of course.
>
> Yes and No. If you talk about mapping, the file size is not a concerne on
> 64bits , but if you want to read to file into memory, it is.
> Not that the operation will failed, but most of the actual machines have
> less than 4 GB of physical memory, so it's going to swap.
Yes, the problems I was talking about were in the context of memory
mapping. Obviously if you read a large file without memory mapping
then you have to worry about *actual* memory usage, not just logical
address space usage.
Mike
_______________________________________________
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