Re: call_func is expensive // Phix much slower
- Posted by Spock Aug 01, 2017
- 1745 views
Using call_func to select the desired "compare" function in a sorting algorithm looks very expensive.
Basic sorting algorithms an be used for a variety of uses if you choose the correct "compare" function.
-- compare "if" vs "call_func" atom t = time() integer void integer count = 1_000_000 puts(1, "compare inside an `if` branch\n\n" ) -- use "if" to select a suitable compare function t = time() for i=1 to count do if 1 then void = compare( 4, 3) end if end for ? time() - t function kustom( object left, object right ) return compare( left, right ) end function integer rid = routine_id( "kustom" ) puts(1, "\ncall_func inside an 'if` branch\n\n" ) -- use "call_func" to select a suitable compare function t = time() for i=1 to count do if 1 then void = call_func( rid, {4, 3} ) end if end for ? time() - t
Some results I get; comparative time in seconds.
OE interpret | OE compiled | p interpret | p -c compiled | |
---|---|---|---|---|
if | 0.01 | 0 | 0.01 | 0 |
call | 0.05 | 0.02 | 0.3 | 0.26 |
The application for call_func would be to select sorting direction (up, down); sort (numbers) or collate (alphanumeric); user custom sort.
It looks like a sort API requires separate functions for each category of sorting--if we wish to maintain the idea that Euphoria is "fast." Is the expense of one "sort" function worth it?
_tom
The figures might be more indicative if the loop count were higher (eg, 100 million) as some timings might get swamped by the timer resolution. In any case, indirect calls were always going to be slower than something else. I imagine that custom sorts would be kinda rare and maybe not so important? In my day to day work the typical sort comparisons are only for strings or ints or fp values - which are all handled by compare(). I only ever used custom_sort() in a few rare cases where that API didn't handle the specific semantics, eg, sorting an index via another index via a data source.
Spock