Re: Changing NSDocument's default saving behavior
Re: Changing NSDocument's default saving behavior
- Subject: Re: Changing NSDocument's default saving behavior
- From: Greg Herlihy <email@hidden>
- Date: Sun, 26 Feb 2006 15:23:09 -0800
- Thread-topic: Changing NSDocument's default saving behavior
The default save behavior of NSDocument is basically to rename the existing
file, write out the document to a new file in a temporary directory, move
that saved file from the temporary directory to its final location, then
delete the old file that was renamed in the first step. Now renaming,
moving, deleting files all require little time, and that amount of time is
more or less constant with little correlation to the size of the files
involved.
That leaves writing out the file as the only potential target for
optimization - but optimization here would only be possible if it were the
case that writing over an existing file is materially faster than writing
out to a newly created file on disk. I tried a few informal benchmarks but
found little indication there is much of a difference. I did discover though
that disk I/O can be very fast on a G5. Using only Carbon file manager
routines, it is possible to write out 18MB of data in 1,152 16K separate
write calls and finish in a quarter of a second.
But for more real-world file I/O numbers, I would recommend profiling with
fs_usage. An fs_usage log timestamps each file system call and includes the
amount of time, if any, a call spent waiting for the I/O request to
complete.
It also seems to me that the larger the file in question, the more reason
there is to ensure that it is saved safely. After all, NSDocument's default
saving behavior benefits larger files more often than it does smaller ones -
because the more time it takes to write out a file, the more likely some
type of failure that aborts the operation will occur. In other words, with
large files, there is a greater chance that the backup will be needed some
day. Moreover large files are often considered more "valuable" then smaller
ones, because of the greater amount of information stored (and the
corresponding increased difficulty in recreating a large datasets, should
someone trip over the power cord while that file was being saved).
Greg
On 2/26/06 11:40 AM, "Stephen F. Booth" <email@hidden> wrote:
> I would like to customize the way my NSDocument subclass saves files.
>
> As best I can tell, the default behavior of NSDocument is to first
> save the file to a temporary location (for me /private/tmp/XXX), then
> copy the temporary file over the original. I assume this is done for
> purposes of trying to keep operations atomic, or preventing data loss
> in case of a network error for NFS (or something more cosmic I didn't
> think of).
>
> This behavior works well for small files, plists, or when the entire
> data of the file is used or manipulated by the application. However,
> I have written an editor for metadata in FLAC and Ogg Vorbis files.
> These files are large, generally several MB, but the metadata is
> typically only the first 8-10 KB. I would like to be able to do an
> "in-place" save, modifying the original file versus being forced to
> copy the original to the save destination, then modifying the copy,
> which is then subsequently renamed. The performance hit for saving
> an 18 MB FLAC file this way versus modifying the metadata in place is
> simply enormous!
>
> Which methods would I need to override to achieve this? I have tried
> everything I can think of; I am able to modify the original file in
> place (simply by using [self fileURL] as the path, but the save
> operations are reported as failing to the user, since the temporary
> file is not being created.
>
> Thanks,
> Stephen
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden