refactor: move bsearch function to C-code

[eloycoto]

This commit fixes issue #527 and move the bsearch function to a native C-code.

The performance is a bit better:

Testing script:

clear
if [[ `uname` == Darwin ]]; then
    MAX_MEMORY_UNITS=KB
else
    MAX_MEMORY_UNITS=MB
fi

export TIMEFMT='%J   %U  user %S system %P cpu %*E total'$'\n'\
'avg shared (code):         %X KB'$'\n'\
'avg unshared (data/stack): %D KB'$'\n'\
'total (sum):               %K KB'$'\n'\
'max memory:                %M '$MAX_MEMORY_UNITS''$'\n'\
'page faults from disk:     %F'$'\n'\
'other page faults:         %R'

echo "JQ code bsearch"
time /usr/bin/jq -n '[range(30000000)] | bsearch(3000)'

echo "C code bsearch"
time ./jq -n '[range(30000000)] | bsearch(3000)'

Results:

JQ code bsearch
3000
/usr/bin/jq -n '[range(30000000)] | bsearch(3000)'   8.63s  user 0.77s system 98% cpu 9.542 total
avg shared (code):         0 KB
avg unshared (data/stack): 0 KB
total (sum):               0 KB
max memory:                823 MB
page faults from disk:     1
other page faults:         432828
C code bsearch
3000
./jq -n '[range(30000000)] | bsearch(3000)'   8.44s  user 0.74s system 99% cpu 9.249 total
avg shared (code):         0 KB
avg unshared (data/stack): 0 KB
total (sum):               0 KB
max memory:                824 MB
page faults from disk:     0
other page faults:         432766

The results may be better if we can use jvp_array_read, and there is no need to copy/free the input array in each iteration. I guess that is like that for API pourposes when the libjq is in use with multiple threads in place.

---

Closes #527

[eloycoto]

@emanuele6 I think this is ready

[itchyny]

The bsearch filter should support searching from an array of any kind.

 $ jq -n '[{x:range(3),y:range(3)}] | debug(. == sort) | bsearch({x:1,y:1})'
["DEBUG:",true]
4

[eloycoto]

@emanuele6 @itchyny I've just refactored this, and merging should be okay.

[itchyny]

I found a regression. On updating tests see my review comment above.

 $ jq -n '[1,2] | bsearch(2)'          
1
 $ ./jq -n '[1,2] | bsearch(2)'
-3

[itchyny]

I think we can reduce special cases, simplify the logic.

static jv f_bsearch(jq_state *jq, jv input, jv target) {
  if (jv_get_kind(input) != JV_KIND_ARRAY) {
    return type_error(input, "cannot be searched from");
  }
  int start = 0;
  int end = jv_array_length(jv_copy(input));
  jv answer = jv_invalid();
  while (start < end) {
    int mid = (start + end) / 2;
    int result = jv_cmp(jv_copy(target), jv_array_get(jv_copy(input), mid));
    if (result == 0) {
      answer = jv_number(mid);
      break;
    } else if (result < 0) {
      end = mid;
    } else {
      start = mid + 1;
    }
  }
  if (!jv_is_valid(answer)) {
    answer = jv_number(-1 - start);
  }
  jv_free(input);
  jv_free(target);
  return answer;
}

[emanuele6]

Here you are leaking target; you need to free it before returning.
Otherwise looks good to me.

[emanuele6]

Maybe also add a test with a non-array input, and a target that uses allocated memory (e.g. a string), so this can be caught by the CI?

[emanuele6]

I just remembered that (start + end) / 2 for binary search is not recommended because it can overflow.
This can be avoided using start + (end - start) / 2 instead.
See https://en.wikipedia.org/wiki/Binary_search_algorithm#Implementation_issues

.

[wader]

Looks good to me, I'm a bit surprised of the small performance difference, calling overhead etc in both cases are larger than the binary search or something?

[itchyny]

I'm a bit surprised of the small performance difference, calling overhead etc in both cases are larger than the binary search or something?

Because [range(30000000)] took most of the time in the entire query.
Reading the target array from file is better in comparing the performance,
but it still costs, so it cannot compare only of bsearch.

 $ jq -nc '[range(3000000)]' > /tmp/x.json
 $ hyperfine --warmup 10 'jq "bsearch(100)" /tmp/x.json' './jq "bsearch(100)" /tmp/x.json'
Benchmark 1: jq "bsearch(100)" /tmp/x.json
  Time (mean ± σ):     575.6 ms ±   5.4 ms    [User: 513.4 ms, System: 56.1 ms]
  Range (min … max):   570.1 ms … 588.7 ms    10 runs

Benchmark 2: ./jq "bsearch(100)" /tmp/x.json
  Time (mean ± σ):     478.9 ms ±   3.9 ms    [User: 419.8 ms, System: 52.6 ms]
  Range (min … max):   473.4 ms … 483.5 ms    10 runs

Summary
  ./jq "bsearch(100)" /tmp/x.json ran
    1.20 ± 0.01 times faster than jq "bsearch(100)" /tmp/x.json

 $ jq -nc '[range(10000000)]' > /tmp/x.json
 $ hyperfine --warmup 10 'jq "bsearch(100)" /tmp/x.json' './jq "bsearch(100)" /tmp/x.json'
Benchmark 1: jq "bsearch(100)" /tmp/x.json
  Time (mean ± σ):      2.002 s ±  0.056 s    [User: 1.759 s, System: 0.208 s]
  Range (min … max):    1.956 s …  2.121 s    10 runs

Benchmark 2: ./jq "bsearch(100)" /tmp/x.json
  Time (mean ± σ):      1.683 s ±  0.077 s    [User: 1.435 s, System: 0.203 s]
  Range (min … max):    1.612 s …  1.821 s    10 runs

Summary
  ./jq "bsearch(100)" /tmp/x.json ran
    1.19 ± 0.06 times faster than jq "bsearch(100)" /tmp/x.json

[itchyny]

Merging, but with dropping the misleading profiling result comments.