feat: parallel preview processing#2569
Conversation
CatsDeservePets
left a comment
There was a problem hiding this comment.
I know this is just a draft but making preview processing non-deterministic is a bad idea. It introduces race conditions. Most obvious when drawing images to the terminal directly (required for unsupported protocols like kitty). Images get drawn in the wrong order and overlap each other.
| workers := max(2, runtime.NumCPU()/2) | ||
| for i := 0; i < workers; i++ { | ||
| go func() { | ||
| for w := range nav.workChan { | ||
| nav.preview(w.path, ui.wins[len(ui.wins)-1], w.mode) | ||
| } | ||
| }() | ||
| } | ||
|
|
There was a problem hiding this comment.
Quoting gopls:
for loop can be modernized using range over int [default]
This should now be fixed by only using parallel workers for preload |
Addresses #2566
This PR is a very simple and small addition that speeds up preview generation (with or without preload) by using parallel processing of preview files. The number of workers is half the available cpu cores, which avoid a configuration setting and should provide a reasonable approach regardless of hardware.