Why not join force with pazi? about zoxide HOT 4 CLOSED

pazi does seem to have very different goals, although it is a very interesting project. Could you elaborate on what you mean by join forces? Is there any feature of pazi that you would like to see in zoxide?

from zoxide.

I think I would just wanted to know how the 2 tools compared and wondering if they were duplicating the effort for nothing. When I see 2 very similar tools I always wonder why the missing features were not applied to the oldest project.

I hope I don't sound rude. I don't there's a lot of reasons to have multiples tools.

from zoxide.

I tried out pazi today. Here's what I gathered:

1. pazi has a far more complex matching algorithm than zoxide. It uses multiple algorithms in sequence to find the best match. On the other hand, zoxide has a simpler matching algorithm, but I find it quite effective, and it works well enough in day-to-day use.

2. Possibly as a result of its increased complexity, pazi's performance suffers. Here's some benchmarks I ran with a database of 1000 entries:

   $ hyperfine 'zoxide query test' -w 1000 -r 5000
   Benchmark #1: zoxide query test
     Time (mean ± σ):       0.4 ms ±   0.1 ms    [User: 0.5 ms, System: 0.4 ms]
     Range (min … max):     0.2 ms …   2.1 ms    5000 runs
   
     Warning: Command took less than 5 ms to complete. Results might be inaccurate.
     Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
   
   $ hyperfine 'pazi jump test' -w 1000 -r 5000
   Benchmark #1: pazi jump test
     Time (mean ± σ):      16.8 ms ±   0.5 ms    [User: 14.6 ms, System: 2.2 ms]
     Range (min … max):    16.0 ms …  27.4 ms    5000 runs
   
     Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
   

   I have not used pazi much, but I did try different queries (exact match, absolute path, no match) to see if I was hitting a possible worst case. Query times were 12.5ms-23.2ms, compared to zoxide's 0.3ms-0.4ms.

   pazi's database additions were also slower, averaging at around 11.0ms, compared to zoxide's 0.6ms. While pazi compensates for this using a fork+exec to run the update in the background, zoxide's speed means that it can be called synchronously without slowing down the shell.

   Another point of comparison I see here is binary sizes. Rust binaries are usually on the larger side, but zoxide is 2.4M compared to pazi's 4.2M. I suspect LTO can be of significant help here.

3. pazi can be used with different fuzzy selectors, while also having an inbuilt number-based selector of its own. This is an interesting idea, but I personally prefer better integration with a sensible default like fzf. This lets us do things like use fzf's gutter to display frecency, which pazi does not support.

   On a side note, users should be able to use zoxide with other fuzzy selectors once #75 is implemented.

All in all, pazi is a fantastic project in its own right, but it does differ from zoxide in terms of its design goals. I hope this answers your question!

from zoxide.

I hope this answers your question!

Yes. Thank you very much.

from zoxide.