Re: "Once-a-day" long delay before startup

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 19, 10:36am, Vincent Lefevre wrote:
} Subject: Re: "Once-a-day" long delay before startup
}
} That can be annoying. But I don't really understand. What if none
} of the concerned directories are group-writable? I suppose that
} getent should be useless. Why not calling it only when needed?

The test is written to find the directories that are both writable
and owned by the user/group in a single glob pass.  It comes down
to predicting whether two globs are slower than one getent, which
isn't practical.  But the test could be rewritten.

On Aug 19, 11:08am, Vincent Lefevre wrote:
}
} With HASH_DIRS, couldn't zsh fill the hash table only when the
} directory is accessed?

Yes, that is what it does, except during completion when it fills
the whole thing so as not to miss some possible completions.  But
whether incremental filling is any faster depends on the order of
the path and where the command is found in it.

Again the optimization chosen years ago was for commands you have
yet to use; a better one nowadays might be to assume command use is
mostly repetitive and only store individual commands as they are
found.  Except, again, for the completion issue, which usually makes
all of this discussion moot.

} Now, if zsh could fill the hash tables in background, this would be
} even better.

That could require completely rewriting the way the shell interacts
with the user for I/O -- I'm not even sure it's possible to maintain
POSIX compliance and do that.  Shells generally don't support shared
memory multithreading, and you'd still have to wait for the table to
be completely filled when completion begins, so you need a sempahore
as well.

However, it might be possible to *cache* the hash table in a manner
similar to the way completion caches work.