La plupart des shells modernent conservent une liste des exécutables disponibles dans les répertoires du PATH ; celle-ci est généralement créée au premier appel d'un binaire sans en donner le chemin absolu, et peux-être mise à jour(par exemple lorsque l'utilisateur change son PATH), par des commandes ad hoc (hash -r, rehash, etc).
Seule cette opération de mise en cache est relativement longue; ensuite, il n'y a pas de pénalité à avoir un PATH de grande longueur.
Pour les bibliothèques, c'est un peu la même chose.
Sur un système correctement administré, la quasi totalité des bibliothèques dynamiques dont auront besoin les programmes sont dans les chemins du système (/etc/ld.so.conf), et une recherche prémachée à l'intention de ld.so, effectuée par les soins de ldconfig au démarrage du système, est disponible (/var/run/ld.so.cache ou approchant, selon le système).
Si l'utilisateur a besoin d'utiliser la variable LD_LIBRARY_PATH, ce ne sera que pour un ou deux répertoires et de manière occasionnelle.
La encore, on ne peut pas considérer qu'il y a une perte de performance.
[^] # Re: Y'a pas 50 solutions
Posté par Miod in the middle . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 10.
Seule cette opération de mise en cache est relativement longue; ensuite, il n'y a pas de pénalité à avoir un PATH de grande longueur.
Pour les bibliothèques, c'est un peu la même chose.
Sur un système correctement administré, la quasi totalité des bibliothèques dynamiques dont auront besoin les programmes sont dans les chemins du système (/etc/ld.so.conf), et une recherche prémachée à l'intention de ld.so, effectuée par les soins de ldconfig au démarrage du système, est disponible (/var/run/ld.so.cache ou approchant, selon le système).
Si l'utilisateur a besoin d'utiliser la variable LD_LIBRARY_PATH, ce ne sera que pour un ou deux répertoires et de manière occasionnelle.
La encore, on ne peut pas considérer qu'il y a une perte de performance.