Performance issues with remote locations

[unode]

I regularly work with remote locations mounted locally (NFS. sshfs...). These have variable latency due to network and I/O load.

After using enhancd for a few weeks and populating enhanced.log with over 3000 entries, issuing a simple cd takes between 3-5 seconds and over 10 seconds when the remote locations are under medium load. This happens even when only issuing commands that primarily target local directories.

I assume most of the delay originates from enhancd checking which directories are still reachable and slowing down when validating remote locations.
Is there any way to profile enhancd and pinpoint the source of slowness?

Contrasting this with fasd, that has been a companion for many years without major performance issues, I find 2-3 seconds a bit too much to be bearable on such an essential command.
As such is there any way to tweak enhancd to avoid hitting these performance issues?

I'm very much enjoying the interaction but the delay is ruining the experience.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[unode]

One week old and marked as stale? Quite an aggressive stale bot.

[crhg]

I also encountered a similar problem. It will wait for a while until it wakes up if my home NAS is in power saving mode.

The existence check is done by __enhancd::filter::exists() function in src/filter.sh.

__enhancd::filter::exists()
{
    local line

    while read line
    do
        if [[ -d $line ]]; then
            echo "$line"
        fi
    done
}

As a workaround, I redefine this function in .zshrc after enhancd is loaded.

__enhancd::filter::exists()
{
    local line

    while read line
    do
        if [[ $line == /Volumes/* || -d $line ]]; then
            echo "$line"
        fi
    done
}

In this example, the existence check is skipped under /Volumes/.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Hi there! This has been closed due to lack of activity. Please comment if you would like it re-opened.

[babarot]

Sorry for late! Not staled.. I'll see this issue soon

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[babarot]

Hmm, I think we have 2 options:

• Skip registering the path to enhancd.log
• Skip checking existence in that case

Which one is suitable for these user experiences? Or any other alternatives?

[babarot]

This is related to #77

[crhg]

I prefer this one.

• Skip checking existence in that case

The reason is that sometimes I want to cd to a directory on a slow disk, it is useful to be able to find it in the history.

[babarot]

@crhg

I prefer this one.

• Skip checking existence in that case

The reason is that sometimes I want to cd to a directory on a slow disk, it is useful to be able to find it in the history.

Thank you for the reply!

OK, I'll follow this approach and implement based on this logic soon.

[HaleTom]

Cheers @crhg for the workaround.

Perhaps the solution is to provide an array:

blacklist_globs=( "/Volumes/*"  "/mnt/ssh/*" ...)

Then if line matches any of the globs, print and return.

I'm thinking regexes would be more powerful, but globs faster, and will cover most cases. Thoughts?