Date: Sat, 11 Aug 2018 02:57:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching Message-ID: <bug-230491-227-Foww7ICqGr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230491-227@https.bugs.freebsd.org/bugzilla/> References: <bug-230491-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230491 --- Comment #12 from commit-hook@freebsd.org --- A commit references this bug: Author: cem Date: Sat Aug 11 02:56:44 UTC 2018 New revision: 337600 URL: https://svnweb.freebsd.org/changeset/base/337600 Log: stat(1): cache id->name resolution When invoked on a large list of files, it is most common for a small numb= er of uids/gids to own most of the results. Like ls(1), use pwcache(3) to avoid repeatedly looking up the same IDs. Example microbenchmark and non-scientific results: $ time (find /usr/src -type f -print0 | xargs -0 stat >/dev/null) BEFORE: 3.62s user 5.23s system 102% cpu 8.655 total 3.47s user 5.38s system 102% cpu 8.647 total AFTER: 1.23s user 1.81s system 108% cpu 2.810 total 1.43s user 1.54s system 107% cpu 2.754 total Does this microbenchmark have any real-world significance? Until a use c= ase is demonstrated otherwise, I doubt it. Ordinarily I would be resistant to optimizing pointless microbenchmarks in base utilities (e.g., recent tota= lly gratuitous changes to yes(1)). However, the pwcache(3) APIs actually simplify stat(1) logic ever so slightly compared to the raw APIs they wra= p, so I think this is at worst harmless. PR: 230491 Reported by: Thomas Hurst <tom AT hur.st> Discussed with: gad@ Changes: head/usr.bin/stat/stat.c --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230491-227-Foww7ICqGr>