Improve search performance by not wasting cycles
Improve search performance by not wasting cycles

Using pick with a large number of choices is slow. The threshold on my
computer is somewhere around 10k lines of input. Benchmarking the
filtering revealed that the scoring is the bottleneck. This is no
surprise since the current search algorithm is an O(n^2) operation in
worst case. The second most time consuming task is the sorting of the
choices. However, the time taken for qsort(3) is consistent and several
order of magnitude less time consuming than the scoring.

When the user inputs a query longer greater than 1 character we
currently waste lots of cycles by performing a search every time a new
character is received. Even if the current query is outdated since the
user already has typed more character yet to be processed. Therefore,
abort the search if there is unprocessed user input available. This is
done by performing a non-blocking poll(2) call on the user input file
descriptor. The check for new input is done on every 50:th iteration.
The number is empirically chosen and close to the number of lines in my
terminal. There's no guarantee that this number is optimal for everyone.
Experimenting with the number on different computers is therefore of
interest.

This change gives the notion of a responsive interface even when the
input is large. Running the following command prior and after this
change should result in a noticeable speed-up:

  $ find ~ | pick

I think this a decent trade-off in terms of gained performance vs.
complexity.

While at it, remove a cast by changing the type of the local i variable
and replace pre-increment with post-increment.

thoughtbot/pick,calleerlandsson/pick,prahlad37/pick,calleerlandsson/pick,prahlad37/pick,thoughtbot/pick,thoughtbot/pick,thoughtbot/pick,prahlad37/pick,calleerlandsson/pick,DBOTW/pick,prahlad37/pick,DBOTW/pick,DBOTW/pick