Preview performance

[q3cpma]

Hello everybody, finally migrated from ranger to lf and I'm truly enjoying the speed and better design. The only bugbear I currently got that I don't understand is the following:

I use chafa in ASCII mode to produce image previews, using the following code:

handle_image()
{
    local fmt=$(cat <<-EOF
                Format:     %m
                Dimensions: %[width]x%[height] px
                Colorspace: %[colorspace]
                Bitdepth:   %[bit-depth]
            EOF
          )
    [ "${mime:-}" = image/jpeg ] &&
        fmt=$(printf '%s\nQuality:    %%Q\n' "$fmt")
    bwrap_auto magick identify -format "$fmt\n" -- "$1[0]" 2>&1
    if command -v chafa >/dev/null
    then
        draw_line $width
        bwrap_easy -r "$path" chafa -s ${width}x${height} \
            --animate off --polite on -t 1 --bg black "$path"
    fi
}

And I added a disk based cache to my preview script:

# Persistent mtime-based cache
cache_path=~/.cache/lf/previews/${width}x${height}$path
[ "$path" -ot "$cache_path" ] && { cat "$cache_path"; exit; }
mkdir -p "$(dirname -- "$cache_path")"
trap 's=$?; exec 1>&3 3>&-; [ $s -ne 0 ] && { rm "$cache_path"; exit $s; }; cat "$cache_path"' EXIT
exec 3>&1 >"$cache_path"

which works fine (easy to see on slow preview handlers).

But the first time showing "large" previews (50~100 KB) for a new client has a pretty important latency (0.5~1s and I'm on a very beefy machine). I suppose then that the cache mentioned in the doc is client-side? But I'm a bit surprised at the performance simply reading that preview from the process.

Can anyone explain the "why" to me? Otherwise, I guess I'll try to time some parts in the preview() function. Maybe some buffering issue.

This is using lf fe3a97c built on Gentoo.

[MahouShoujoMivutilde]

I've tried implementing my own cache and it seems to always work much faster than re-rendering with chafa.

Details

#!/bin/bash
# preview script

export WIDTH="$2"
export HEIGHT="$3"

case "$(file -L -b --mime-type -- "$1")" in
image/*)
    cache="/tmp/lf-img/$(sha256sum -- "$1" | awk '{print $1}')_${WIDTH}x${HEIGHT}.ascii"
    mkdir -p "$(dirname -- "$cache")"

    if [ "$1" -ot "$cache" ]; then
        start="$(date +%s.%N)"
        cat "$cache"
        end="$(date +%s.%N)"

        total="$(echo "$end - $start" | calc -p)" # or | bc -l instead of calc
        notify-send "$(basename -- "$1" | cut -c 1-15)... ${total}s from cache"
        exit 0
    fi

    start="$(date +%s.%N)"
    chafa -f symbols --animate off --polite on -t 1 --bg black \
        -s "${WIDTH}x${HEIGHT}"  -- "$1" | tee "$cache"
    end="$(date +%s.%N)"

    total="$(echo "$end - $start" | calc -p)"
    notify-send "$(basename -- "$1" | cut -c 1-15)... ${total}s via chafa"
    exit 0
    ;;
*)
    echo no preview implemented
    ;;
esac

start/end are leftovers from the test with sixel, which works similarly, with cache always being much faster.

Time

chafa -f symbols ... is typically 0.14s when lf is fullscreened, on very much dated ryzen 2700 pc inside lf running in foot terminal (wayland) for 12MP photos. Resulting .ascii files are ~150kb.

So 0.5-1s on something modern is strange.

Lf's builtin cache (current instance only) also doesn't have any meaningful delay, though I can't measure that from the script.

I don't see an increased delay on 0da0d79, so I don't know what is going on in your preview script, but maybe you can get ideas from the snippet above to solve it.

[q3cpma]

Thanks a lot for the attention, it may help me!

[q3cpma]

I've replaced my script with a simple cat of a single already cached preview (size: 220K).

#!/bin/sh -eu
cat ~/.cache/lf/previews/129x86/home/user/DSC00171_crop.jpg

only the first display was slow!

Then I tried allowing normal txts:

#!/bin/sh -eu
case "$path" in
	*.txt) cat "$path";;
	*) cat ~/.cache/lf/previews/129x86/home/user/DSC00171_crop.jpg;;
esac

Result: previewing a few txts was fast, previewing the first non-txt was laggy, then it was fast again.

Then I tried again the normal script: the lag was there on all pictures (with previews of different size). Hmmm...

Methinks it may be some buffer (possibly internal to Go's stdlib) caching mechanism or something. I'll probably dive into the code next week-end.

NB: the cache is on an NVMe drive