On 8/24/13 11:38 PM, Kyle Sluder wrote:
On Sat, Aug 24, 2013, at 02:31 PM, Markus Spoettl wrote:
That's exactly what I'm doing. My save times are so bad, the only
explanation
that I can come up with is that UIDocument/NSFileWrapper isn't really
hard-linking unchanged wrappers. Or it does and also does something else
to
counter the gain.
Rather than guess, you should measure.
* What does -matchesContentsOfURL: say when sent to your sub-wrappers?
* Does -matchesContentsOfURL: even get called?
* What does Instruments say is actually going on?
Sure could do that, but I fail to see how it would help solving the issue. I did
measure that -write
-writeContents:toURL:forSaveOperation:originalContentsURL:error:
is where the time is lost, so it's within the UIDocument/NSFileWrapper
implementation. However, since there's no way to actually alter it, there's no
way to fix it.
I did a parallel implementation that walks the NSFileWrapper hierarchy, does its
own checks using -matchesContentsOfURL: and writes data or hard links
accordingly. That worked more or less, -matchesContentsOfURL did work. But the
point is, I had to redo the whole thing, there's no way to make the existing
implementation behave differently. Even if there was a way through sub-classing
NSFileWrapper, it certainly isn't documented and thus it's a no-no.
I ended up completely dumping NSFileWrapper altogether. One problem with it (and
that's a big one on iOS) is that a wrapper will hold on to the data after it has
been written to the disk. In my case that's a lot of data and after it's saved I
don't need it (quickly). I need the wrapper, though, to access it later should I
need to, so I can't just dump the wrapper. There's no elegant way to get rid of
it, you'll have to use -readFromURL::: which adds insult to injury as it's
costly in a wrapper structure of hundreds or thousands of files.
Another problem, the one that actually pushed me over the cliff, was that when
reading a wrapper structure lazily (that is, creating the URL directory wrapper
NOT specifying NSFileWrapperReadingWithoutMapping), and you have a couple of
hundred wrappers you need to get data from, iOS will shoot your process down
after 600 or so (in my case, not sure if it depends on file size). It took a
while to find out what the cryptic Xcode errors and crash logs meant. My process
was running out of vnodes to map files.
I conclude that NSFileWrapper, which works great on OSX, is unusable for me on
iOS with my particular requirements.
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
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
