• 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: NSFileHandle or a better way?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSFileHandle or a better way?


  • Subject: Re: NSFileHandle or a better way?
  • From: Keary Suska <email@hidden>
  • Date: Fri, 30 Jan 2009 09:08:35 -0700


On Jan 30, 2009, at 7:44 AM, Jaime Magiera wrote:

I've been using NSFIleHandle for a project that inserts data into a file and synchs it back to disk. Everything went smoothly until the app started getting used for larger files ( > 200 megs). First, I ran into the NSFileHandle -> NSData 256 megs conundrum. That was solved by, as others suggested on this list in other threads, iterating with readDataOfLength or availableData instead of a single readDataToEndOfFile. That worked well. I've got pools set up to keep the memory down. The problem now is that the reads are still really slow. For example, with a read length of 50 megs, I can only get in 3 reads per second. My apps ends up taking almost a minute to perform all of its functions on a file of 500 megs.

Perhaps my overall approach was wrong to start out. What I've been doing is opening a file handle, copying the data after the insertion point to an NSData, truncating the file handle at the insertion point, adding the new data, then adding back the trimmed data. This works fairly well if the insert point is towards the end of the file. However, there are instances where I need to insert a few hundred kb into a the file at a location only a few hundred kb into the file.

xxx ^ xxxxxxxxxxxxxxxxx

The time hit comes from copying the trim data to the NSData. Is there a better way to do this with NSFileHandle? Is there a better way to do this than NSFileHandle?

I suspect your bottleneck is the filesystem. To know for sure you could try the raw C calls and see if it speeds up. In any case, instead of doing a grow/shrink on the file, write to a temp file instead then swap them. This way you could also do optimized batch- writes. This alone could speed the process up immensely. Notwithstanding, how do you recover if your app crashes after you truncate the file?


HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

_______________________________________________

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


  • Follow-Ups:
    • Re: NSFileHandle or a better way?
      • From: Jaime Magiera <email@hidden>
References: 
 >NSFileHandle or a better way? (From: Jaime Magiera <email@hidden>)

  • Prev by Date: Re: Disabling sorting in a programatically generated table
  • Next by Date: Re: Sizing table columns to fit data - a solution looking for suggestions
  • Previous by thread: NSFileHandle or a better way?
  • Next by thread: Re: NSFileHandle or a better way?
  • Index(es):
    • Date
    • Thread