Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os_info shouldn't call out to external commands on Linux (it is slow) #383

Open
VorpalBlade opened this issue Jul 17, 2024 · 2 comments
Open

Comments

@VorpalBlade
Copy link

I have a program that runs for a very short time (<100 ms), that needs to know what Linux distro it is on. Unfortunately using os_info results in a lot of (relative) overhead due to it calling out to external binaries. About 35 ms extra in fact. The program runtime is performance criticial, it gets invoked many times from a shell script.

It seems that lsb_release is the worst offender (at ~35 ms). Removing lsb_release from path brings the overhead down to a more manageble ~4-5 ms. There is an old issue #319 about this, but no progress.

The remaining invoked programs seem to be:

  • getconf
  • uname
  • Somehow reinvoking the program itself? At least it looks like that in perf/hotspot:
    image

Both getconf and uname should be possible to replace with calls to nix, libc or even rustix.

I have no idea why it looks like os_info is reivoking my program (paketkoll) though. But that shouldn't be needed either really. And yes, that extra process goes away if I remove os_info (and hard code in what distro is in use, in this case Arch Linux).

@stanislav-tkach
Copy link
Owner

I agree with your concerns, but unfortunately I don't have time right now to fix that. Hopefully I will be able to look into that in about a month, but I don't want to promise anything. I welcome pull requests if you would like to implement that yourself.

@ydirson
Copy link
Contributor

ydirson commented Jul 30, 2024

I would argue that a frequently-running tool does not really need to call os_info every time, since that info is unlikely to change. Even if it would avoid calling lsb_release it would do extra work you don't need.
I suggest caching the info you need in /run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants