I think we may be in the territory of pre-mature optimization. There is
going to be a bit more overhead creating a copy-on-write object than a
pass-by-reference object, but the real gains (over the old way) are going
to be seen with objects that are “large”. If you run a profiler and need to
improv
Mark Wieder wrote:
> On 05/06/2018 02:42 PM, Richard Gaskin via use-livecode wrote:
>
>> Did copy-on-write get changed in v9, or is the scope of its effects
>> just more limited than I had understood it to be?
>
> I'm still at the point of not trusting copy-on-write yet, but I think
> you're misi
On 05/06/2018 02:42 PM, Richard Gaskin via use-livecode wrote:
Did copy-on-write get changed in v9, or is the scope of its effects just
more limited than I had understood it to be?
I'm still at the point of not trusting copy-on-write yet, but I think
you're misinterpreting your results. If I'
I doubt if it would work out faster. A quick test of
time ls -lR > null
gives 166 ms vs. the 179 I get from the non-recursive tree walker - so
by the time you gather that output, and re-format back to something more
usable, I think you'd probably come out the same or slower.
Alex.
On 06/0
On 06/05/2018 20:12, Richard Gaskin via use-livecode wrote:
Ah, that makes sense. It's not so much the recursion per se, but the
more general advantage of inline processing vs handler calls.
Exactly.
In the test case below you know how many levels deep you're going,
which seems a good fit f
there's actually a directory walker search one can use in a shell command
on mac that is quite speedy...
let me report back.
sqb
--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
On Sun, May 6, 2018 at 2:29 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> M
Bernd wrote:
> Richard wrote:
>> Which version of LC did you test with?
>> I was under the impression that since LC switched to copy-on-write
>> for all >arguments we should no longer need to use "@" for
>> performance, only for for logic.
>
>
> I tested using LC 9 GM, what kind of results do you
Malte Pfaff-Brill wrote:
> I wonder if shelling out to DIR on Windows and LS on Linux/Mac
> wouldn’t be the fastest option…
Maybe, but there's overhead in setting up the shell session.
Even if it's measurably faster, I would be surprised if it were
noticeably faster.
Anything that depends on
>Which version of LC did you test with?
>I was under the impression that since LC switched to copy-on-write for all
>>arguments we should no longer need to use "@" for performance, only for for
>logic.
Richard,
I tested using LC 9 GM, what kind of results do you get?
Kind regards
Bernd
___
I wonder if shelling out to DIR on Windows and LS on Linux/Mac wouldn’t be the
fastest option…
Cheers,
Malte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
pre
Bernd Niggemann wrote:
> a combination of "private" and referenced variables (@) improves the
> speed of the calls somewhat.
Which version of LC did you test with?
I was under the impression that since LC switched to copy-on-write for
all arguments we should no longer need to use "@" for perfo
Alex,
a combination of "private" and referenced variables (@) improves the speed of
the calls somewhat.
Kind regards
Bernd
--
on mouseup
local t1, t2
constant K = 1000
local x
constant KX = 100
put the millisecs into t1
repeat K
Ah, that makes sense. It's not so much the recursion per se, but the
more general advantage of inline processing vs handler calls.
In the test case below you know how many levels deep you're going, which
seems a good fit for inline loops. But how do we handle cases like
directory traversal, w
On 05/05/2018 01:29, Richard Gaskin via use-livecode wrote:
How does recursion impair performance so significantly?
In general, there's significant work involved in a function or handler
call and return - you need to establish a new context for locals, copy
or calculate, parameters, etc. My c
Alex Tweedly wrote:
> Avoiding recursion is (almost) always a good idea, if it can be
> done without jumping through hoops; for a file walker I timed it
> (a couple of years ago) at somewhere between 20 and 35% faster.
How does recursion impair performance so significantly?
--
Richard Gaskin
Thanks Ben - that's pretty similar to what I use. Avoiding recursion is
(almost) always a good idea, if it can be done without jumping through
hoops; for a file walker I timed it (a couple of years ago) at somewhere
between 20 and 35% faster.
And it's so much easier to add a good progress indi
FWIW I don't use recursion for directory walking. My typical routine (typing
directly into email, may contain errors) is something along the following lines:
-- assumes tRootFolder is the path to start reviewing
put return into tFoldersToDo
repeat until tFoldersToDo = emp
Ah, it will throw an error - so best to use try / catch around the function
calls.
On Sat, Apr 21, 2018 at 9:13 AM Ali Lloyd wrote:
> Now that we have files(pFolder), folder(pFolder) (and files(pFolder,
> "detailed"), folders(pFolder, "detailed")), directory walking code can be
> improved somewh
Now that we have files(pFolder), folder(pFolder) (and files(pFolder,
"detailed"), folders(pFolder, "detailed")), directory walking code can be
improved somewhat by not having to set the current folder.
Actually, I haven't checked what happens when you get
files(pRestrictedFolder)
On Fri, Apr 20,
You may recall the dreaded recursion errors that have cropped up in
discussions of directory walkers. They happen not because anyone has
directory trees > 40,000 folders deep, but because a permissions
restriction can prevent going into a subdirectory, causing the current
directory to be trave
> On 19 Apr 2018, at 11:20, Sannyasin Brahmanathaswami via use-livecode
> mailto:use-livecode@lists.runrev.com>> wrote:
>
> Never mind…
>
> I found this in a toolbox. Sent by some ago, by a LiveCode deva
That looks very much like the code supplied under the “Resources” menu, from
Tutorials>
Never mind…
I found this in a toolbox. Sent by some ago, by a LiveCode deva
For what it's worth :
# Filters the strings "." and ".." from a list
function filterDots pList
local tList
put pList into tList
filter tList without "."
filter tList without ".."
return tList
end
I have directory available this days of Ken Ray, in the on system of set the
default folder and get the the files, registered that path. descend recursively
to the level… etc.
Do anyone has a new one handy they could share using the folder and file
function?
BR
__
23 matches
Mail list logo
