mise hook-env slow in pathetic deep directories #4327
Unanswered
TobiX
asked this question in
Troubleshooting and bug reports
Replies: 3 comments 4 replies
|
debug/trace might lend more insight. I am pretty sure what is happening is it's looking for all the combinations of different |
3 replies
|
I was thinking the same, but adding Uhm. futex? I'm confuse. |
|
Here is a trace with extra timestamps: |
|
And since I was already benchmarking, here is a GNUplot (Path-length vs. execution time): |
|
I'll note for the record that this behavior gets really bad if you are browsing a network-mounted filesystem, as the roundtrip seems to absolutely kill performance. A roundtrip of 5-10ms means that because We can validate that performance by using filter that down with: And I get the following info (rightmost column has the time taken for each stat call as a fraction of seconds, most taking ~12ms): While I'm here, I'll note that unfortunately, I cannot find any configuration where I can add these network filesystems to a list where mise should just not run at all, so with mise it becomes impossible to even browse a single network drive. The configuration I tried was Version and timing info from mise when I ran that strace: |
1 reply
|
I did come up with a workaround to allow me to totally block ## Paste this somewhere after the line in your .bashrc where mise gets set up, looks like this:
# eval "$($HOME/.local/bin/mise bash)"
# We want to add a little indirection where we can put our own logic to prevent running mise on slow
# network filesystems. When we 'cd' into a directory in Bash, how is mise hook-env getting run? The
# callgraph looks like this:
#
# $PROMPT_COMMAND -> _mise_hook -> eval "$(mise hook-env -s bash)"
#
# Thus, it seems like the thing to do is to try to re-define the `_mise_hook` function so that it
# won't run in blocklisted paths.
# In order to change the _mise_hook implementation so that it won't run `mise hook-env -s bash` if
# our current directory is in one of the blocklisted folders, we unset it then define it anew.
# Original source for _mise_hook is:
# https://github.com/jdx/mise/blob/e4888902195528bcb65767841f8b9f3daa8195f3/src/shell/bash.rs#L58
unset _mise_hook
DONT_RUN_MISE_PATHS=(
"/run/user"
"/mount/"
)
_should_run_mise() {
local curdir="$1"
for exempt_path in "${DONT_RUN_MISE_PATHS[@]}"; do
# Normalize paths by removing trailing slashes
exempt_path="${exempt_path%/}"
if [[ "$curdir" == "$exempt_path" || "$curdir" == "$exempt_path"/* ]]; then
return 1
fi
done
return 0
}
_mise_hook() {
local previous_exit_status=$?;
if _should_run_mise "$PWD" ; then
eval "$(mise hook-env -s bash)";
fi
return $previous_exit_status;
}Putting the above into my .bashrc has worked perfectly to solve my problems. |
|
I retested this against the current There have been two relevant improvements since this was reported:
For example, users on slow network filesystems can configure a short cache window and/or limit full checks to directory changes: [settings]
hook_env.cache_ttl = "5s"
hook_env.chpwd_only = trueIf config discovery should be excluded under an entire mount, # .miserc.toml
ignored_config_paths = ["/mount"]On Unix it can alternatively be set with Based on the current timings and these built-in controls, the original deep-directory performance issue appears to be resolved. If anyone can still reproduce a substantial delay on a current release, especially on a particular network filesystem, an updated timing/trace would be helpful. AI-assisted — Tool: Codex; model: OpenAI/GPT-5; version: unavailable. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Doing a test with PATH_MAX limits I noticed that hook-env seems to be getting slower & slower the deeper the directory structure gets. Using the commands from https://darnassus.sceen.net/~hurd-web/faq/foo_max/ I didn't get very far. With a path "only" ~150 directories deep I get the following timings:
(Last line is from the zsh time feature)
Output of doctor in this directory:
All reactions