|
|
Log in / Subscribe / Register

Why glibc's fstat() is slow

Why glibc's fstat() is slow

Posted Sep 15, 2023 9:18 UTC (Fri) by dottedmag (subscriber, #18590)
Parent article: Why glibc's fstat() is slow

Every time I see "this is to simplify code" I flinch. People so often lose the sight of what they are doing: any software project is producing software to be used by the users, and that's the main goal. The secondary, subordinate, goal is to make the developers' lifes as easier as possible. For such a fundamental library as libc any inefficiency is multiplied gazillion times every day. In my opinion it is cruel to put developers' time above users' in this particular codebase.

Admittedly, C is such a footgun that sacrificing some performance in some rare corner cases to significantly decrease amount of code is acceptable, but selecting one syscall over another in stat, is it really so complicated?

P.S: I'm not ordering anyone to do anything, I'm posting my observations and describe attitude I try to put into my work. I thank all maintainers who put their work into the code we all benefit from, often without renumeration and in their spare time, and I try to pay it back in kind.


to post comments

Why glibc's fstat() is slow

Posted Sep 16, 2023 15:14 UTC (Sat) by Paf (subscriber, #91811) [Link]

I mean, they didn’t realize it was slower.

Simpler code is a net good, freeing up time and making bugs less likely, and if you can get it without trade offs, you should do it. It seems reasonable to believe the perf would be ~the same, which they did.

So maybe they need better testing but they didn’t do anything *wrong* and certainly didn’t knowingly prioritize convenience over performance.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds