revCopyFile

[Geoff Canyon]

It is stunning to me that this is faster than using a shell command. I did
the same test as before (about thirty files, about 70k each) and copying
them by using binary reads/writes took about one-third the time of using
the shell command. I thought it might be overhead with calling shell, but I
ran it on a single 50MB file, and the binary read/write method was better
than twice as fast there as well. What *possible* overhead could there be
in a shell command that would make it better than twice as slow as
reading/writing the file 16kb at a time?

On Thu, Mar 22, 2012 at 6:11 PM, Maarten Koopmans <
maarten.koopmans at gmail.com> wrote:

> I scripted this using the read as binary etc. using 16KB buffers some time
> ago in pure LC. Much faster, and cross-platform.  Idon'thave the code here
> at hand, but it is really straightforward:
>
> Open the source file for read binary
> Open the destination file for write binary
> Read 16KB or whatever is left if it's less from the source into a buffer
> Append the buffer to the destination
> Loop until done
> Close the files
>
> Faster then revCopyFile (in fact, why doesn't itdo it this way....) and no
> hassle with shells or external processes where you need to check if they
> actually did what you asked.
>
> HTH, Maarten
>
> On Thursday, March 22, 2012, Pete <pete at mollysrevenge.com> wrote:
> > Hi Geoff,
> > Thanks for the speed test info.  I'm not very familiar with shell
> commands
> > so maybe you could let me know the command to use? What I need to do is
> > copy a file to a different folder with a different file name.
> >
> > The lack of a progress bar might be a problem, but if the speed
> differences
> > are as much as you found, there may not be a need for a progress bar at
> all.
> >
> > Also, I assume the shell commands would be different on Windows and Mac.
> >  That's an inconvenience because it means extra coding, but not a show
> > stopper.
> >
> > Thanks,
> > Pete
> >
> > On Wed, Mar 21, 2012 at 11:25 PM, Geoff Canyon <gcanyon at gmail.com>
> wrote:
> >
> >> The advantages derive from the fact that LiveCode isn't doing the actual
> >> copying with revCopyFile -- the Finder is. For completeness, the same
> >> advantage applies to using a shell command. You don't get a progress
> dialog
> >> though.
> >>
> >> Okay, I just did a quick one-off test with interface sounds off. For
> thirty
> >> files that were each about 70kb, using a shell command was about 3x
> faster
> >> than using revCopyFile. That's without taking advantage of the ability
> to
> >> move and rename in one step with a shell command. If that's what you're
> >> doing, the advantage would be even greater.
> >>
> >> On Wed, Mar 21, 2012 at 3:04 PM, Pete <pete at mollysrevenge.com> wrote:
> >>
> >> > Thanks all for the input.  Sounds like Stephen's approach is the only
> way
> >> > to get rid of it.  Seems like that setting will apply to other sounds
> as
> >> > well, but I'm OK with that.
> >> >
> >> > As far as using AppleScript, I'm using revCopyFile because the
> dictionary
> >> > claims there are "certain advantages" to using it over "put URL" or
> any
> >> > other method, amongst which is that it does not require reading the
> file
> >> > into memory, and since some of these files could be pretty large,
> that's
> >> > significant.  On a Mac, it also displays a progress bar which I don;t
> >> think
> >> > would be possible if I used "put URL".
> >> >
> >> > Pete
> >> >
> >> > On Wed, Mar 21, 2012 at 11:35 AM, Geoff Canyon <gcanyon at gmail.com>
> >> wrote:
> >> >
> >> > > I went straight to the shell command, so I don't know for sure, but
> >> this
> >> > > sounds reasonable. There's also the overhead of spinning up
> AppleScript
> >> > in
> >> > > the first place. If Apple is doing that badly, that might also cause
> >> > > problems I suppose.
> >> > >
> >> > > On Wed, Mar 21, 2012 at 1:24 PM, stephen barncard <
> >> > > stephenREVOLUTION2 at barncard.com> wrote:
> >> > >
> >> > > > That was probably a big reason why multiple file transfers would
> take
> >> > > more
> >> > > > time - loading and unloading the sound - and perhaps the reason
> why
> >> it
> >> > > > failed after memory was exceeded.
> >> > > >
> >> > > _______________________________________________
> >> > > use-livecode mailing list
> >> > > use-livecode at lists.runrev.com
> >> > > Please visit this url to subscribe, unsubscribe and manage your
> >> > > subscription preferences:
> >> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Pete
> >> > Molly's Revenge <http://www.mollysrevenge.com>
> >> > _______________________________________________
> >> > use-livecode mailing list
> >> > use-livecode at lists.runrev.com
> >> > Please visit this url to subscribe, unsubscribe and manage your
> >> > subscription preferences:
> >> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> >
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >
> >
> > --
> > Pete
> > Molly's Revenge <http://www.mollysrevenge.com>
> > _______________________________________________
> > use-liv
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>