Richard Gaskin wrote:
So this tells me two things:

1. Using a function for a sortKey expression introduces a "sometimes" rule in terms of understanding the order of expression evaluation in the engine, in which most of the time functions are evaluated first but in this case the function is applied repeatedly for each line of the sort container as the sort command is run.

2. Using a function as a sortKey expression evaluates the sort container as though by effectively adding data to it, rather than anything necessarily in the data itself.

Both of these are very valuable insights. Thanks to all who helped explain this.

Yes indeed, now I can see many areas where this can be useful, but it also leaves me with a question:

Given #1 above, how does this affect performance? Unless there's something ultra-tricky going on (wouldn't be the first time the engine surprised me that way <g>), I would imagine that performance is affected at least linearly, in which the overhead of the function call is multiplied by the number of lines of the container to arrive at the additional performance hit relative to a non-custom sort.

Perhaps I'll do some benchmarking to verify this theory....

FWIW, I ran some benchmarks and it turns out the theory seems to hold up, in which the time taken for a custom function sort is roughly the same as the time to call the function multiplied by the number of lines of the data being sorted, plus the time of the sort itself.

This isn't surprising given how it works, but may be helpful if an alternative algorithm for what you want to accomplish is available.

But given the grace of the syntax and the reasonably good performance of the engine overall, if you need to use it you'll likely be hard-pressed to come up with anything that does that which is faster.

For benchmarking fetishists, the code I tested is below.....

--
 Richard Gaskin
 Fourth World Media Corporation
 ___________________________________________________________
 [EMAIL PROTECTED]       http://www.FourthWorld.com


on mouseUp
  put 1000 into n -- number of iterations to test
  put fld 1 into tData -- data to sort (mine was 535 lines)
  put the number of lines of tData into tLineNum -- for use in results
  --
  -- 1: Test time to call function
  put the millisecs into t
  repeat n
    get foo()
  end repeat
  put the millisecs - t into t1
  --
  -- 2: Test time to do straight sort
  put tData into tmp
  set the itemdel to tab
  put the millisecs into t
  repeat n
    sort lines of tmp by item 2 of each
  end repeat
  put the millisecs - t into t2
  --
  -- 3: Time to do custom sort:
  put tData into tmp
  put the millisecs into t
  repeat n
    sort lines of tmp by foo()
  end repeat
  put the millisecs - t into t3
  --
  -- Results:
  put "For "&n&" iterations - "&\
      cr&"Time to call foo: "&t1  &\
      cr&"Time to perform simple sort: "&t2 &\
      cr&"Time to perform foo sort: "& t3 &\
      cr&"(foo time * number of lines)+ simple sort time = "&\
        (t1* tLineNum)+ t2
end mouseUp



-- I tested with two variants of foo, each taking different approaches
-- with very different performance times:

--- Serious time-waster:
function foo
  repeat 100
    get random(9999)
  end repeat
  return it
end foo

-- Just complex enough to be measurable at 1000 iterations:
function foo
  get random(9999)
  add 44 to it
  subtract 4444 from it
  put 1* it into it
  put it div 5 + 6 into it
  get it + it / 4
  get round(it) + 10 + 1 + 1
  return it
end foo

_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to