Replace the per-chunk query cache from []Result slices to fixed-size
bitmaps (ChunkBitmap: [16]uint64 = 128 bytes per entry). Each bit
indicates whether the corresponding item in the chunk matched.
This reduces cache memory by 86 times in testing:
- Old []Result cache: ~22KB per chunk per query (for 500 matches)
- New bitmap cache: ~262 bytes per chunk per query (fixed)
With the reduced per-entry cost, queryCacheMax is raised from
chunkSize/5 to chunkSize/2, allowing broader queries (up to 50% match
rate) to be cached while still using far less memory.
All input lines now enter the chunklist with sequential indices, and
header lines are excluded from matching via Pattern.startIndex and
PassMerger offset. This allows the number of header lines to be changed
at runtime with change-header-lines(N), transform-header-lines, and
bg-transform-header-lines actions.
- Remove EvtHeader event; header items are read directly from chunks
- Add startIndex to Pattern and PassMerger for skipping header items
- Add targetIndex field to Terminal for cursor repositioning across
header-lines changes
Close#4659
With chunkSize=100 and 10M items, 100K chunks cause ~300K mutex
lock/unlock operations per search across 32 goroutines competing
for a single sync.Mutex in ChunkCache.
Increasing to 1000 reduces chunks to 10K, cutting contention overhead.
Benchmarks on 10M items show 14-80% faster searches depending on query
selectivity.
This command would cause a deadlock and make fzf crash:
fzf --bind 'start:reload:ls' --height ~100%
Because,
1. 'start' event is handled by Terminal
2. When 'reload' is bound to 'start', fzf avoids starting the initial reader
3. Terminal waits for the initial input to find the right height when
adaptive height is used
4. Because the initial reader is not started, Terminal never gets the
initial list
5. No chance to trigger 'start:reload', hence deadlock
This commit fixes the above problem by extracting the reload command
bound to 'start' event and starting the initial reader with that command
instead of letting Terminal start it.
This commit also makes the environment variables available to
$FZF_DEFAULT_COMMAND.
FZF_DEFAULT_COMMAND='echo $FZF_QUERY' fzf --query foo
Fix#3944
Fix#2212
# Will start rendering after 200ms, update every 100ms
fzf --preview 'for i in $(seq 100); do echo $i; sleep 0.01; done'
# Should print "Loading .." message after 500ms
fzf --preview 'sleep 1; for i in $(seq 100); do echo $i; sleep 0.01; done'
# The first line should appear after 200ms
fzf --preview 'date; sleep 2; date'
# Should not render before enough lines for the scroll offset are ready
rg --line-number --no-heading --color=always ^ |
fzf --delimiter : --ansi --preview-window '+{2}-/2' \
--preview 'sleep 1; bat --style=numbers --color=always --pager=never --highlight-line={2} {1}'
In #1061 we changed the default command to retry with a simpler find
command with fewer arguments if the first find command failed. This was
to support stripped-down verions of find that do not support -fstype
argument.
However, this caused an unwanted side-effect of yielding duplicate
entries when the first command failed after producing some lines.
We revert the change in this commit, so the default command will not
work with find without -fstype support. But we now print better error
message in that case so that the user can set up a working
$FZF_DEFAULT_COMMAND.
Close#1120#1167
Instead of notifying the event coordinator (EventBox) whenever a new
line is arrived, start a background goroutine that periodically does the
task. Atomic.StoreInt32 is much cheaper than mutex synchronization
that happens during EventBox update.
