Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

CopyFileTo Speed (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: OS X Background only Plist solution
Next thread: Problems with Exceptions (was Re: Bizarre problem with canvas)


CopyFileTo Speed   -   Roland Voegtli
  Re: CopyFileTo Speed   -   Joseph J. Strout
   Re: CopyFileTo Speed   -   Dominik Fusina - The Captain
    Re: CopyFileTo Speed   -   Frank Bitterlich
     Re: CopyFileTo Speed   -   Dominik Fusina - The Captain
     Re: CopyFileTo Speed   -   Norman Palardy
      License code problems?   -   Stephen Adams
    Re: CopyFileTo Speed   -   Norman Palardy
  Re: CopyFileTo Speed   -   Roland Voegtli
   Re: CopyFileTo Speed   -   Aaron Ballman
    Re: CopyFileTo Speed   -   Roland Voegtli
    Re: CopyFileTo Speed   -   James Sentman
  Re: CopyFileTo Speed   -   Alfred Van Hoek
   Re: CopyFileTo Speed   -   Dominik Fusina - The Captain

CopyFileTo Speed
Date: 30.07.02 20:06 (Tue, 30 Jul 2002 21:06:47 +0200)
From: Roland Voegtli
G'day gentlemen.

I have a quick question about the speed of FolderItem.CopyFileTo.
I want to copy around 50 megs in 6 files at startup of the
app (backing up database files, if user desires). If I copy
these files on OS X 10.1.5 (PB G4/550) the Finder needs around
10 seconds to do the job.

If I use "sourceFile.CopyFileTo targetFolder", the compiled
app requires for the same job 110 seconds. And the HD is making
noises like it's moving bazillions of terrabytes...

Is this method supposed to be so slow, or am I doing something
terribly wrong?

Best regards
Roland

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 30.07.02 20:41 (Tue, 30 Jul 2002 12:41:19 -0700)
From: Joseph J. Strout
At 9:06 PM +0200 7/30/02, Roland Voegtli wrote:

>I have a quick question about the speed of FolderItem.CopyFileTo.
>I want to copy around 50 megs in 6 files at startup of the
>app (backing up database files, if user desires). If I copy
>these files on OS X 10.1.5 (PB G4/550) the Finder needs around
>10 seconds to do the job.
>
>If I use "sourceFile.CopyFileTo targetFolder", the compiled
>app requires for the same job 110 seconds. And the HD is making
>noises like it's moving bazillions of terrabytes...
>
>Is this method supposed to be so slow

Yes, we copy everything 10 times just so people buy faster computers. ;)

No, seriously though, the Finder's copy code is highly optimized
(especially in OS X) at all sorts of low levels that we don't have
access to. We're just using the ordinary file-copying API calls that
Apple provides to us. So I'm not surprised that the Finder is
faster, but I am surprised at what a large difference you're seeing.
Such a large difference may indicate a bug; I suggest you report it
with REALbugs.

Meanwhile, as a work-around, consider using an embedded AppleScript
or AppleEvents to have the Finder copy the files for you.

HTH,
- Joe

Re: CopyFileTo Speed
Date: 31.07.02 07:02 (Wed, 31 Jul 2002 08:02:53 +0200)
From: Dominik Fusina - The Captain
on 30/07/02 21:41, Joseph J. Strout at <email address removed> wrote:

> Yes, we copy everything 10 times just so people buy faster computers. ;)
Really ? ((((((-:
>
> No, seriously though, the Finder's copy code is highly optimized
> (especially in OS X) at all sorts of low levels that we don't have
> access to. We're just using the ordinary file-copying API calls that
> Apple provides to us. So I'm not surprised that the Finder is
> faster, but I am surprised at what a large difference you're seeing.
> Such a large difference may indicate a bug; I suggest you report it
> with REALbugs.
>
> Meanwhile, as a work-around, consider using an embedded AppleScript
> or AppleEvents to have the Finder copy the files for you.
In the same subject, I would like to know if it's possible to know the
number of "octets" writed in real time by the "CopyFileTo" function ?
You know, it's sometimes (particulary when the file is big) very useful to
know the size of datas in writing and - for the user - display a bar.

Thanx,

Dominik Fusina
Captain of NEMO


---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 31.07.02 11:12 (Wed, 31 Jul 2002 12:12:46 +0200)
From: Frank Bitterlich
Dominik Fusina - The Captain wrote:
> In the same subject, I would like to know if it's possible to know the
> number of "octets" writed in real time by the "CopyFileTo" function ?
> You know, it's sometimes (particulary when the file is big) very useful to
> know the size of datas in writing and - for the user - display a bar.

I doubt it, since the CopyFileTo command is somewhat atomic in RB - it
halts your application (or thread) until the copy is done. So if you
want to get progress information, I guess you have to write your own
copy method. Not too hard unless you're including the resource fork, too ;)

Cheers,
Frank+++

Re: CopyFileTo Speed
Date: 31.07.02 11:18 (Wed, 31 Jul 2002 12:18:32 +0200)
From: Dominik Fusina - The Captain
on 31/07/02 12:12, Frank Bitterlich at <email address removed> wrote:

> I doubt it, since the CopyFileTo command is somewhat atomic in RB - it
> halts your application (or thread) until the copy is done. So if you
> want to get progress information, I guess you have to write your own
> copy method. Not too hard unless you're including the resource fork, too ;)
I agree, not hard (resource fork is not hard too), but slower.


Dominik Fusina
Captain of NEMO


---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 31.07.02 19:36 (Wed, 31 Jul 2002 12:36:27 -0600)
From: Norman Palardy
I have one that includes copying the resource fork

On Wednesday, July 31, 2002, at 04:12 AM, Frank Bitterlich wrote:

> Dominik Fusina - The Captain wrote:
>> In the same subject, I would like to know if it's possible to know the
>> number of "octets" writed in real time by the "CopyFileTo" function ?
>> You know, it's sometimes (particulary when the file is big) very
>> useful to
>> know the size of datas in writing and - for the user - display a bar.
>
> I doubt it, since the CopyFileTo command is somewhat atomic in RB - it
> halts your application (or thread) until the copy is done. So if you
> want to get progress information, I guess you have to write your own
> copy method. Not too hard unless you're including the resource fork,
> too ;)

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 31.07.02 19:34 (Wed, 31 Jul 2002 12:34:10 -0600)
From: Norman Palardy
If you need such a thing then I have a function that lets you copy about
the same speed as the built in CopyFileTo that you could advance a
progress bar as you copy

On Wednesday, July 31, 2002, at 12:02 AM, Dominik Fusina - The Captain
wrote:

> on 30/07/02 21:41, Joseph J. Strout at <email address removed> wrote:
>
>> Yes, we copy everything 10 times just so people buy faster
>> computers. ;)
> Really ? ((((((-:
>>
>> No, seriously though, the Finder's copy code is highly optimized
>> (especially in OS X) at all sorts of low levels that we don't have
>> access to. We're just using the ordinary file-copying API calls that
>> Apple provides to us. So I'm not surprised that the Finder is
>> faster, but I am surprised at what a large difference you're seeing.
>> Such a large difference may indicate a bug; I suggest you report it
>> with REALbugs.
>>
>> Meanwhile, as a work-around, consider using an embedded AppleScript
>> or AppleEvents to have the Finder copy the files for you.
> In the same subject, I would like to know if it's possible to know the
> number of "octets" writed in real time by the "CopyFileTo" function ?
> You know, it's sometimes (particulary when the file is big) very useful
> to
> know the size of datas in writing and - for the user - display a bar.

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 30.07.02 21:36 (Tue, 30 Jul 2002 22:36:47 +0200)
From: Roland Voegtli
Joe,

>Yes, we copy everything 10 times just so people buy faster computers. ;)

So, I assume copying takes 5% of the time and the rest is the the
cleanup routine? :-)

>No, seriously though, the Finder's copy code is highly optimized

Hell. My RB code is that as well! It's just one Line! <g>


>what a large difference you're seeing. Such a large difference may
>indicate a bug; I suggest you report it with REALbugs.

I have to verify that on a desktop machine before I real bug it.

>Meanwhile, as a work-around, consider using an embedded AppleScript
>or AppleEvents to have the Finder copy the files for you.

I'm going for win32 too...

Thanks for the hint.

Kind regards
Roland

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 30.07.02 21:46 (Tue, 30 Jul 2002 15:46:22 -0500)
From: Aaron Ballman
on 7/30/02 3:36 PM, Carnivore devoured Roland Voegtli at
<email address removed>'s message:

>> Meanwhile, as a work-around, consider using an embedded AppleScript
>> or AppleEvents to have the Finder copy the files for you.
>
> I'm going for win32 too...
>
The Win32 folder item code calls straight thru to the system, so any
slowdown that occurs there will occur with any other application on Windows.
_Shouldn't_ be an issue there with just using CopyFileTo.

~Aaron

Re: CopyFileTo Speed
Date: 30.07.02 21:52 (Tue, 30 Jul 2002 22:52:00 +0200)
From: Roland Voegtli
>The Win32 folder item code calls straight thru to the system, so any
>slowdown that occurs there will occur with any other application on Windows.
>_Shouldn't_ be an issue there with just using CopyFileTo.

Ok. Thanks for the hint. Although I feel pretty bad to deliver
a worse performance on the Mac than on win32. ;-)

Roland

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 30.07.02 22:29 (Tue, 30 Jul 2002 17:29:17 -0400)
From: James Sentman
>>The Win32 folder item code calls straight thru to the system, so any
>>slowdown that occurs there will occur with any other application on Windows.
>>_Shouldn't_ be an issue there with just using CopyFileTo.
>
>Ok. Thanks for the hint. Although I feel pretty bad to deliver
>a worse performance on the Mac than on win32. ;-)

if you're on MacOSX you can do a shell call to the "ditto" program
and as long as you pass the -rsrcFork option it will preserve all the
Mac specific stuff. This is part of the standard Mac OSX install and
does not require the developer tools. It does require the BSD
subsystem stuff, but that is part of the standard install now too,
but people may have unchecked it during a fresh OS install...

-James

Re: CopyFileTo Speed
Date: 31.07.02 15:50 (Wed, 31 Jul 2002 10:50:59 -0400)
From: Alfred Van Hoek
on 7/31/02 9:00 AM, Frank Bitterlich" <<email address removed>> wrote:

> Subject: Re: CopyFileTo Speed
> From: "Frank Bitterlich" <<email address removed>>
> Date: Wed, 31 Jul 2002 12:12:46 +0200
>
> Dominik Fusina - The Captain wrote:
>> In the same subject, I would like to know if it's possible to know the
>> number of "octets" writed in real time by the "CopyFileTo" function ?
>> You know, it's sometimes (particulary when the file is big) very useful to
>> know the size of datas in writing and - for the user - display a bar.
>
> I doubt it, since the CopyFileTo command is somewhat atomic in RB - it
> halts your application (or thread) until the copy is done. So if you
> want to get progress information, I guess you have to write your own
> copy method. Not too hard unless you're including the resource fork, too ;)
>

Hmm, if you want to be able to have a progress bar, I suggest to use the
QTFileTransfer Plugin;

it does CopyRemoteFileToLocalFile and takes an URL as argument. Similarly,
you could use URLAccess plugin. Both are available on my web:

Alfred

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: CopyFileTo Speed
Date: 31.07.02 15:57 (Wed, 31 Jul 2002 16:57:43 +0200)
From: Dominik Fusina - The Captain
on 31/07/02 16:50, Alfred Van Hoek at <email address removed> wrote:

> Hmm, if you want to be able to have a progress bar, I suggest to use the
> QTFileTransfer Plugin;
>
> it does CopyRemoteFileToLocalFile and takes an URL as argument. Similarly,
> you could use URLAccess plugin. Both are available on my web:
>
> Alfred
Thanx Alfred.


Dominik Fusina
Captain of NEMO



---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>