On Mar 3, 2014, at 14:26 , Trygve Inda wrote:
> I did some testing
>
> All 3750 in one folder: 40 seconds to save.
>
> Split into two levels: 16 folders -> 16 folders -> image files: 5 sec
>
> Three levels: 16 folders -> 16 folders -> 16 folders -> image files: 10 sec
It seems to me this
>
I did some testing about optimal number
> of files per folder for our package
format and 3750 files per directory are
> way too many. The file system is much
more efficient if you spread those
> files into sub-folders. We got the best performance with a 3-level sparse
> folder index (files are
If you do end up writing your own safe-saving logic, that's achieved by
overriding -writeSafelyToURL:…
Sent from my iPad
On 2 Mar 2014, at 15:23, Trygve Inda wrote:
>> 7,500 file operations of any kind are going to take some time, even just
>> creating hard links. Does it require 40 seconds? W
> Can't say, probably less than 100 per folder. It's easy to find out, though,
> just create different layouts and see which one is getting saved most
> quickly. I
can remember that we experimented extensively with the number of
> index levels
(each level having 16 potential slots) and 3 turned o
On 3/2/14 5:22 PM, Trygve Inda wrote:
I did some testing about optimal number of files per folder for our package
format and 3750 files per directory are way too many. The file system is
much
more efficient if you spread those files into sub-folders. We got the
best
performance with a 3-level
> I did some testing about optimal number of files per folder for our package
> format and 3750 files per directory are way too many. The file system is
> much
more efficient if you spread those files into sub-folders. We got the
> best
performance with a 3-level sparse folder index (files are st
On 3/2/14 3:43 PM, Trygve Inda wrote:
-Root
- plist file (about 20mb)
- Folder containing 3750 image files of about 50kb each
- Folder containing 3750 image files of about 100kb each
I did some testing about optimal number of files per folder for our package
format and 3750 files per directory
> 7,500 file operations of any kind are going to take some time, even just
> creating hard links. Does it require 40 seconds? Well, I don't know. But I do
> seriously doubt that it could be done in 1 second.
>
> You might try it out yourself, write test code to create a new package, walk
> through
>> A follow up...
>>
>> Adding this to my NSDocument subclass:
>>
>> - (BOOL)writeToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
>> forSaveOperation:(NSSaveOperationType)saveOperation
>> originalContentsURL:(NSURL *)absoluteOriginalContentsURL error:(NSError
>> **)outError
>> {
>>NSE
7,500 file operations of any kind are going to take some time, even just
creating hard links. Does it require 40 seconds? Well, I don't know. But I do
seriously doubt that it could be done in 1 second.
You might try it out yourself, write test code to create a new package, walk
through your pac
> You also need to overwrite
> - (void)setFileURL:(NSURL *)absoluteURL
>
> in which you call super and then update your stored wrapper (if you have one
>
already) using -[NSFileWrapper readFromURL:options:error:].
>
> You need to do this because the filewrapper you return in -fileWrapperOfType
On 3/2/14 12:06 AM, Quincey Morris wrote:
> I’ve never used this, but I *have* seen documents use hard linking anyway
> (though, on reflection, that might have been UIDocument, not NSDocument — I’m
> not sure now).
No, it is NSDocument/NSFileWrapper, UIDocument/NSFileWrapper doesn't know this
ki
On 2 Mar 2014, at 00:40, Trygve Inda wrote:
>>
>> On 1 Mar 2014, at 23:26, Trygve Inda wrote:
>>
>>> I have a top level FileWrapper which contains the wrappers for all my files.
>>> Is there any sample code that would help me figure out the right way to do
>>> this?
>>>
>>> [NSFileWrapper wr
>
> On 1 Mar 2014, at 23:26, Trygve Inda wrote:
>
>> I have a top level FileWrapper which contains the wrappers for all my files.
>> Is there any sample code that would help me figure out the right way to do
>> this?
>>
>> [NSFileWrapper writeToURL:options:originalContentsURL:error:]
>>
>> See
>
> On 1 Mar 2014, at 23:26, Trygve Inda wrote:
>
>> I have a top level FileWrapper which contains the wrappers for all my files.
>> Is there any sample code that would help me figure out the right way to do
>> this?
>>
>> [NSFileWrapper writeToURL:options:originalContentsURL:error:]
>>
>> See
On 1 Mar 2014, at 23:26, Trygve Inda wrote:
> I have a top level FileWrapper which contains the wrappers for all my files.
> Is there any sample code that would help me figure out the right way to do
> this?
>
> [NSFileWrapper writeToURL:options:originalContentsURL:error:]
>
> Seems to call my
>
> On 1 Mar 2014, at 19:11, Trygve Inda wrote:
>
>>> On Mar 1, 2014, at 07:23 , Trygve Inda wrote:
>>>
The problem is that when there is a very small change (just adding or
removing one of the files in the package), the system does not save in
place.
Rather it reads
On Mar 1, 2014, at 14:53 , Mike Abdullah wrote:
> It is -[NSFileWrapper writeToURL:options:originalContentsURL:error:] which
> has the feature of writing out hard links for efficiency. But it only does it
> if requested, by passing a suitable URL as the original contents URL. It is
> my suspic
On 1 Mar 2014, at 19:11, Trygve Inda wrote:
>> On Mar 1, 2014, at 07:23 , Trygve Inda wrote:
>>
>>> The problem is that when there is a very small change (just adding or
>>> removing one of the files in the package), the system does not save in
>>> place.
>>>
>>> Rather it reads the previous
> On Mar 1, 2014, at 11:11 , Trygve Inda wrote:
>
>> I really need this to be faster.
>
> I think the point I was trying to reach was that your next step is to
> investigate what is taking the time. IIRC there’s a NSURL attribute key you
> can use to retrieve a file’s inode number, so you can ch
> On Mar 1, 2014, at 07:23 , Trygve Inda wrote:
>
>> The problem is that when there is a very small change (just adding or
>> removing one of the files in the package), the system does not save in
>> place.
>>
>> Rather it reads the previous package file completely, writes out a copy of
>> the p
On Mar 1, 2014, at 07:23 , Trygve Inda wrote:
> The problem is that when there is a very small change (just adding or
> removing one of the files in the package), the system does not save in
> place.
>
> Rather it reads the previous package file completely, writes out a copy of
> the package (40
I have a Document whose file type is a package and potentially contains a
few thousand files. My test case is about 7500 files (mostly images).
I am using
-(NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
The problem is that when there is a very small change (j
23 matches
Mail list logo
