Detailed comparison of different hook options

[weilbith]

Sorry to annoy you with such simple issues. But the documentation is not too extensive and I did not look into the code myself so far.
So while setting up zoxide on my PC (coming from fasd), I wonder which hook option I should choose during initialization. Let's disregard none option. For me it looks like the pwd option has the advantage that it does not run so often (depending on the user behavior) and therefore consumes less time (in total). So what is the point of prompt? What I could imagine is that the score of the current working directory increases with each command I run inside. This means the more I'm working inside a specific directory the more "important" it gets. Not sure it that is the case, but this could have a variety of advantages as I could imagine (e.g. git worktrees).
Thanks for your help in advance.

PS: Does it make sense to cache the initialization? That was recommended for fasd and I wonder if this is beneficial here as well to safe shell startup time.

[ajeetdsouza]

@weilbith the default hook is pwd and usually works great for most people. Your intuition is correct - pwd increases the score of a directory whenever you cd into it, and prompt increases the score with every command. pwd is more efficient, since it is called less often, but I wouldn't worry about that - zoxide is quite fast, and doesn't cause any slowdown there.

I personally prefer the pwd hook, because it intuitively makes more sense to me. If I have a directory that I cd into once every morning and use for the rest of the day without ever closing the terminal, that's not a very important directory compared to one I have to cd into and out of 100 times a day (even if it's just a temporary directory).

The advantage of using the prompt hook is that it works even on simpler shells such as dash. Users who use dash regularly with other shells would want to set up the same hook on both - mixing the two would throw off the scores (since the prompt hook increments scores much more frequently).

Does it make sense to cache the initialization?

Not really, since the zoxide binary does most of the work. The only thing it does at shell startup is set up a few aliases. On zsh, zoxide generates 79 lines of code (not counting blank lines/comments), which is barely anything to process.

[weilbith]

Thank you. :🙏

[weilbith]

Not that I mistrusted your statement, but out of curiosity I did a quick performance test. The result:
Plain initialization as documented takes in average on my PC 3.2ms.
Sourcing with using a cache (ofc includes check if cache exists and version update) takes in average 5.1ms.
So it as simple as it can be. 🙃

[ajeetdsouza]

That does make sense, since the startup time of a Linux binary is of the order of a millisecond. 1.9ms of extra startup time is usually not very significant.

As long as you're doing caching with a version check, there should be no problem with it. It'd be nice if you could share how you're caching it, so that others who might be interested are able to do so too.

As a side note, if you're interested in tweaking zoxide for maximum performance, you might want to build zoxide locally using musl:

cargo install --path . --target x86_64-unknown-linux-musl

[weilbith]

As long as you're doing caching with a version check, there should be no problem with it. It'd be nice if you could share how you're caching it, so that others who might be interested are able to do so too.

I'm confused. My result clearly showed that doing caching is slower than working without a cache. So it does not make sense to share it. ^^
It is eventually faster if you really just source a static file. But if you want a more mature solution it is slower as my numbers have "proven".

As a side note, if you're interested in tweaking zoxide for maximum performance, you might want to build zoxide locally using musl:

I think zoxide is really amazingly fast. You did a great job.
But since I'm always curious: what is this improving? Does get rid of all boilerplate to work on differnt OS and makes it only applicable on my system? 🤔

[ajeetdsouza]

caching is slower than working without a cache

I misread - this is what I get for using GitHub on my phone. Are you calling zoxide --version? If so, you're already paying the cost of loading the zoxide binary, so it wouldn't be any faster than calling zoxide init directly. Reading from another file after that would only cause more overhead.

what is this improving?

Most executable files depend on a library called libc. By default, Rust uses an implementation called glibc, but there is an alternate implementation called musl that is designed with different goals in mind. I've found that Rust binaries compiled with musl start up a lot faster. Heavier projects tend to experience a slowdown with musl, but zoxide benefits more from the lower startup times.

[weilbith]

I misread - this is what I get for using GitHub on my phone. Are you calling zoxide --version? If so, you're already paying the cost of loading the zoxide binary, so it wouldn't be any faster than calling zoxide init directly. Reading from another file after that would only cause more overhead.

Yes that makes sense.
I must admit that my statement with the version was wrong. Sorry for that.
But even this code here is not improving anything. It is basically the same time. Just with the disadvantage if there is an update to zoxide, the old cache continuous to get loaded.

[[ ! -s "$ZOXIDE_INIT_CACHE_FILE" ]]  && zoxide init zsh >| "$ZOXIDE_INIT_CACHE_FILE"
source "$ZOXIDE_INIT_CACHE_FILE"

Most executable files depend on a library called libc. By default, Rust uses an implementation called glibc, but there is an alternate implementation called musl that is designed with different goals in mind. I've found that Rust binaries compiled with musl start up a lot faster. Heavier projects tend to experience a slowdown with musl, but zoxide benefits more from the lower startup times.

So why is this not the default option for the distributed binary builds? 🤔

---

Sorry for abusing this issue. But there is still no messaging option in GitHub and I think it is not worth to open an issue for that. And if it should be relevant for other users, they still should be able to find it with the repository search.

So I wanted to get some version of zoxide which acts on the current directory tree only. I extended this with some functions to work on the worktree of the currently inside git repository (especially useful if you have the same repository with multiple worktrees checked out in parallel and all folders are named the same, obviously). I thought if I feed zoxide query with the absolute path of the directory of interest as first keyword and then the rest, this should do the work. But it doesn't.

Lets say that is given:

$ zoxide query --list --score key
20 /foo/bar/key
4 /bar/foo/key

Let's give this a try:

$ zoxide query /bar/foo key
/foo/bar/key

I would have expected that the last query returns /bar/foo/key. How can I achieve this goal?

[ajeetdsouza]

why is this not the default option for the distributed binary builds?

I don't believe Cargo provides a way to set musl targets as default.

Regarding the distributed binaries - I'm not the best person to ask, as I don't package zoxide myself. Rather, that is done by some fantastic maintainers who do a far better job of keeping things upto date than I ever could!

However, from what I've seen, packaging usually involves a script that at some point calls cargo build. This same script can be used across architectures, but we wouldn't be able to do that if we were hardcoding the target.

Of course, one could write a script to pick the musl target appropriate to the architecture we're compiling for, but it's usually far easier and less error-prone to just let Cargo pick the default. The difference in startup time is only 1ms - on my system, the startup time for zoxide with musl and glibc are 0.7ms and 1.7ms respectively.

That said, I do make musl-compiled binaries available on the Releases page.

I would have expected that the last query returns /bar/foo/key

If it's not doing that, it's a bug. Keywords are matched in order, so this shouldn't be happening. I tried something similar on my own system and it worked correctly, so if you could give me an exact sequence of commands that reproduce this behaviour, (mkdir /tmp/foo, cd, etc), that would be helpful.

[weilbith]

Thanks for the exhaustive answer! 🙏
Eventually I'll put an adopted copy of the PKGBUILD file (ArchLinux user here) into my private AUR repository. I mean it is only 1ms and I'll never recognize it. But its a 50% time improvement and I kinda can't ignore that. 😂

---

Okay awkward. I tried to come up with such an example. But it works as you say. So I need to share more "private" infos, since there is definitely a scenario on my PC that does not work. So here is the exact example the question was originated from:

$ zoxide query --list --score dapp
   8 /home/thore/projects/brainbot-projects/repositories/raiden/light-client-test/raiden-dapp
   1 /home/thore/projects/brainbot-projects/repositories/raiden/light-client/raiden-dapp
$ zoxide query /home/thore/projects/brainbot-projects/repositories/raiden/light-client dapp
/home/thore/projects/brainbot-projects/repositories/raiden/light-client-test/raiden-dapp

Just to have some small context, there is a repository called light-client. And there is a second worktree of it that is called light-client-test. Both (of course) have a folder called raiden-dapp. The point is that this is a quite big monorepo. So zoxide a good opportunity to jump fast between the different packages/workspaces of this repo without doing cd ../../other-workspace etc. But since I have this repo twice, zoxide will continuously mix the directories depending on which worktree I used more frequent in the recent past. So I could accidentically switch to the other worktree in-between without noticing it (well I could use the echo setting, but this does not work for zsh-automcomplete or I always need to use the interactive mode).
After all this useless additional information for you: is there eventually something special about the path? Can I somehow escape it to make it bullet-proof?

[ajeetdsouza]

Haha yes, I understand now. Just add a / at the end:

- zoxide query /home/thore/projects/brainbot-projects/repositories/raiden/light-client dapp
+ zoxide query /home/thore/projects/brainbot-projects/repositories/raiden/light-client/ dapp

[weilbith]

Oh wow. That was easy.
But was it working for the example before and not here? 🤔
Anyway, thank you very much for help! 🙏

[ajeetdsouza]

Without the slash, the keyword matches both directory names, so it picks the one with the higher score. Once you add the slash, it needs to match the slash at the end of the directory in the path:

light-client/raiden-dapp
            ^ this one

[weilbith]

Ah I got it. Now I also see the obvious difference to the example case. Makes totally sense. xD