Possible performance loss

[bitstreamout]

I've read https://github.com/openSUSE/libalternatives/blob/master/README.md and I'm not sure if this is a good idea to this that way ... now every binary is in fact the program alt parsing for e.g. the system bourne shell /bin/sh several configuration files before execution instead of direct executing by following the symbolic link (and caching this in the kernels cache for file accesses) ... hence every call for /bin/sh triggers a further parsing of the libalternatives config and takes some ms more for every parsing and execve() call

[danyspin97]

Considering systems with slow disks, that could easily become the bottleneck the system. Maybe the configuration could be cached in /run where there is no delay reading from files there.

[AdamMajer]

So I did a small benchmark where I execute /bin/true either directly or via alts. The expected overhead is additional exec() or 100%. And this appears to be the case,

https://gist.github.com/AdamMajer/89e1402d26024f5ebddb25d19d2f0890

The overhead is mostly the additional exec() and the parsing of the config file appears negligible in comparison. But I do agree with @bitstreamout that /bin/sh is not the best candidate here -- this is more how use use a tool and not the tool problem. I would prefer programs like /bin/sh to have an alternative selection mechanism. For example, having a package like bash_is_sh or dash_is_sh that provide a direct symlink for few, high impact pieces of software like /bin/sh would be better than using one approach only. "If you have a good hammer, everything seems like a nail".

Regarding slow disks, this is not a good argument. The first execution will the few IO hits, but subsequent access should be cached. Slow disks will also result in overheads from dynamic linked libraries as well.