Okay, I think I'm brain damaged -- nope, I figured it out
Geoff Canyon
gcanyon at gmail.com
Sat Sep 14 02:41:54 EDT 2013
On Thu, Sep 12, 2013 at 6:06 PM, Mark Wieder <mwieder at ahsoftware.net> wrote:
> OTOH, this scales linearly and is faster than "before", "after", or
> "into": on a half-fast dual-core linux box I get 103 ticks for a
> million iterations. Even with the overhead of the handler call, it
> looks like this avoids making a copy of the original.
>
This does avoid making a copy, but so does put after.
tl;dr: use put after, and don't use variables to work with more than about
100mb unless you have no choice.
I tested each of the options discussed in this thread. Each test iterates
with an ever-longer target string, until an iteration takes more than a
second to complete.
Here are the timings I got. For each:
-- the first column is the iteration
-- the second is the size of the resulting variable at that step
-- the third is the elapsed time
-- the fourth is the ratio of the time to the previous iteration
-- the fifth is the ratio of the size of the resulting string to the time
taken for that iteration.
None of these test scale against the size of the append string (it's the
same across all the tests and iterations) -- rather, they all test scale
against the size of the target string, which grows at a constant rate for
each of the tests. For that, constant time would be ideal. For example,
within the boundaries of LC's math functions, addition is (nearly) constant
against the size of the target, meaning that on my machine, this takes
about a second regardless of which line I uncomment:
on mouseUp
--put 1 into X
--put 999999 into X
put the long seconds into T
repeat 9999999
add 1 to X
end repeat
put the long seconds - T
end mouseUp
Appending to a string doesn't work that way. The longer the target string
is, the longer the append to it takes. The good news is that it's nowhere
near linear, except for the first two options.
before
put "xxxxxxxxxx" before R
putting a string before a variable is slow, likely because it is either
duplicating the whole string, or because it is shoving over the entire
string to make room at the front. This only got up to a string 800k long
before taking more than a second to iterate. It appears to be roughly
linear on the size of the target string.
1 100000 0.077 0.00006 1298703
2 200000 0.207173 2.690563 965376
3 300000 0.387425 1.870054 774344
4 400000 0.522814 1.349459 765090
5 500000 0.665046 1.272051 751828
6 600000 0.810649 1.218937 740148
7 700000 0.953222 1.175875 734351
8 800000 1.111549 1.166097 719716
put into
put R & "xxxxxxxxxx" into R
putting a string before a variable is also slow, because it likely is
duplicating the whole string. This also only got up to a string 800k long
before taking more than a second to iterate. It appears to be roughly
linear on the size of the target string.
1 100001 0.07383 0.011054 1354479
2 200001 0.189246 2.563273 1056830
3 300001 0.367313 1.940926 816745
4 400001 0.500568 1.362783 799094
5 500001 0.645846 1.290227 774180
6 600001 0.787196 1.21886 762200
7 700001 0.917061 1.164972 763309
8 800001 1.053472 1.148748 759395
append
append "xxxxxxxxxx", R
command append pNew, @pString
put pNew after pString
end append
An append function is much faster. Note that in the previous two tests,
each iteration only appended 100k. This test appended 5mb -- 50x as much --
in each iteration, and also gets up to a 45mb target string before hitting
one second per iteration. The @ means the target is not being duplicated,
but calling the function is still overhead that can be avoided.
1 5000000 0.572176 0.01905 8738570
2 10000000 0.631929 1.104431 15824565
3 15000000 0.684285 1.082851 21920686
4 20000000 0.742656 1.085302 26930369
5 25000000 0.816506 1.09944 30618272
6 30000000 0.869896 1.065388 34486884
7 35000000 0.92884 1.06776 37681403
8 40000000 0.981937 1.057165 40735814
9 45000000 1.022531 1.041341 44008444
put after
put "xxxxxxxxxx" after R
The reigning champ. This is also appending 5mb each iteration, and the
target string hits 85mb before stopping. Still, this is showing substantial
slowing: the last 5mb takes about 17 times as long to append as the second
5mb.
1 5000000 0.114283 0.006386 43751098
2 10000000 0.174828 1.529784 57199058
3 15000000 0.243715 1.394027 61547287
4 20000000 0.29158 1.196397 68591819
5 25000000 0.334841 1.148368 74662300
6 30000000 0.402346 1.201603 74562709
7 35000000 0.469453 1.16679 74554839
8 40000000 0.507524 1.081096 78814005
9 45000000 0.576554 1.136013 78049923
10 50000000 0.625147 1.084281 79981206
11 55000000 0.6839 1.093983 80421100
12 60000000 0.738292 1.079532 81268660
13 65000000 0.812725 1.100818 79977846
14 70000000 0.849118 1.044779 82438484
15 75000000 0.879976 1.036341 85229617
16 80000000 0.931517 1.058571 85881406
17 85000000 1.004347 1.078184 84632097
More information about the use-livecode
mailing list