Re: copyItemAtPath takes double time than the Finder
Re: copyItemAtPath takes double time than the Finder
- Subject: Re: copyItemAtPath takes double time than the Finder
- From: Peter Lübke <email@hidden>
- Date: Thu, 20 Jan 2011 01:56:23 +0100
Why not have the Finder do the job?
You can use AppleEvents to send a duplicate message to the Finder;
you can do it sync (kAEWaitReply) or async (kAENoReply).
Behaviour and performance will be the same as using the Finder,
including proper update of .DS_Store files.
Am 20.01.2011 um 00:49 schrieb Gary L. Wade:
Both FSCopyObjectAsync and FSCopyObjectSync leak memory in Mac OS X
10.6.x, even up to 10.6.6; the async form leaks even more than the
sync
form. Apple has verified this both in my bug, rdar://8734968 (opened
against 10.6.5) and another unspecified one opened earlier in
2010. I've
verified both still leak memory in 10.6.6.
If you are only doing one or two copies per execution of your
application,
the leak is not significant. If you are doing many copies per
execution
of your application (as I must), these leaks are horrible.
Apple has verified there is nothing a developer can do to work
around this
other than to use the Cocoa method.
On 01/19/2011 3:15 PM, "Mike Abdullah" <email@hidden>
wrote:
Well you shouldn't be using this synchronous API for long-running
copy
operations, since it can't be cancelled or give progress.
Instead use FSCopyObjectAsync().
On 19 Jan 2011, at 21:42, Leonardo wrote:
Hi,
I have checked, the Finder, takes only 7 seconds to copy a 500MB dmg
file.
The copyItemAtPath API takes 18 seconds to copy the same file.
Why? Is a way to make copyItemAtPath run at the same Finder speed?
If not, which API should I use to get the same performance?
I use:
[[NSFileManager defaultManager] copyItemAtPath:src toPath:dst
error:&err];
Architectures: ppc, i386
Base SDK: Mac OS X 10.5
Valid Architectures: i386 ppc ppc64 ppc7400 ppc970 x86_64
C/C++ Compiler Version: GCC 4.2
Optimization Level: Fastest [-O3]
Regards
-- Leonardo
_______________________________________________
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