| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
Update tty to print newline as space
Add tty_putc
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the list of candidates was split between threads a priori,
with each thread being evenly distributed a contiguous range from the
search candidates.
This did a bad job of distributing the work evenly. There are likely to
be areas with significantly more matches than others (ex. files within
directories which match the search terms), as well as areas with longer
strings than others (ex. deep directories).
Because of the type of data fzy receives, work allocation needs to be
dynamic.
This commit changes the workers to operate on the candidates in batches,
until they have all been processed. Batches are allocated by locking a
mutex and grabbing the next available range of BATCH_SIZE candidates.
BATCH_SIZE is currently set at 512, which worked best on my laptop in a
quick test. This will always be a compromise. Small batch sizes will
distribute the work more evenly, but larger batch sizes will be
friendlier to CPU caches.
Quick testing:
Before:
./fzy -e drivers --benchmark < linux_files.txt 1.69s user 0.03s system 163% cpu 1.053 total
After:
./fzy -e drivers --benchmark < linux_files.txt 2.12s user 0.02s system 296% cpu 0.721 total
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Since we're dividing the search set equally between processors, we want
to run with the same number of workers that we have CPU execution
threads. This avoids having a worker which is starved until the end of
execution.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
For the empty query, sorting can be the slowest part of the search.
Since the empty query gives no scores, and we've now made our sort
stable, in this case we can simply skip sorting.
A sort of 250000 entries took about ~10ms on my laptop, which is not a
huge amount. However it's not 0 and is free to skip.
|
| |
|
|
|
| |
C's stdlib's qsort isn't a stable sort. We want it to be so that any
equivalent matches are stored in the order they came in.
|
| |
|
