Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] improve performance handling iterm2 image protocol in --preview #3984

Open
6 of 10 tasks
JohnFinn opened this issue Sep 2, 2024 · 0 comments
Open
6 of 10 tasks

Comments

@JohnFinn
Copy link

JohnFinn commented Sep 2, 2024

Checklist

  • I have read through the manual page (man fzf)
  • I have searched through the existing issues
  • For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.55.0 (v0.55.0)

OS

  • Linux
  • macOS
  • Windows
  • Etc.

Shell

  • bash
  • zsh
  • fish

Problem / Steps to reproduce

I noticed that fzf preview takes quite a long time when showing big images with iterm protocol. This gets annoying when browsing filesystem. My measurements has shown that without fzf rendering takes around 25ms and with fzf it gets up to 400ms.

measurement with fzf

# to make sure chafa is not the issue
chafa -f iterm --view-size 91x44 a.png > a.chafa
# fzf preview loads ~400ms
echo foo bar | fzf --preview '/bin/cat a.chafa'
fzf.mp4

fzf opened at 11th frame 0.7333s till preview rendered at 18th frame 1.20s -> 0.4666s

baseline measurement

❯ hyperfine '/bin/cat a.chafa' --show-output
...
  Time (mean ± σ):      25.2 ms ±   1.0 ms    [User: 0.4 ms, System: 10.0 ms]
  Range (min … max):    22.5 ms …  27.9 ms    129 runs
image used ![a](https://github.com/user-attachments/assets/c3a81edd-476d-4b6a-93ac-cb95045eecf7)

Since without fzf the rendering takes much less time, it seems like fzf has quite a lot of overhead somewhere. It would be great to optimize it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant