From 6cd55b966f75aeb94b3f2cd17b806f0330c009fb Mon Sep 17 00:00:00 2001 From: blyxyas Date: Fri, 13 Jun 2025 01:41:03 +0200 Subject: [PATCH] Optimize by 99.75% strlen_on_c_strings, 8.5% globally So this is funny, the query `tcx.module_children` was top 3 in most time consuming functions in Clippy, it was being called 24384 times in tokio. "Unacceptable!" I thought. Digging a bit around, turns out that `clippy::strlen_on_c_strings` was calling for `get_def_path` via `match_libc_symbol`. This query pretty-prints things and performs some analysis. Yes, we were running early lint checks to see if symbols were from `libc`. I don't really trust callgrind when it says I've turn 81 billion instructions into like 10 million. So I benchmarked this the good ol' "compiling 20 times without incr" method and it went from 0.31s-0.45s to 0.25s constistently. (Profiled, and "benchmarked") on tokio. --- clippy_utils/src/lib.rs | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/clippy_utils/src/lib.rs b/clippy_utils/src/lib.rs index 55469e8ebc90..76e4fbe09c54 100644 --- a/clippy_utils/src/lib.rs +++ b/clippy_utils/src/lib.rs @@ -1793,10 +1793,9 @@ pub fn in_automatically_derived(tcx: TyCtxt<'_>, id: HirId) -> bool { /// Checks if the given `DefId` matches the `libc` item. pub fn match_libc_symbol(cx: &LateContext<'_>, did: DefId, name: Symbol) -> bool { - let path = cx.get_def_path(did); // libc is meant to be used as a flat list of names, but they're all actually defined in different // modules based on the target platform. Ignore everything but crate name and the item name. - path.first().is_some_and(|s| *s == sym::libc) && path.last().copied() == Some(name) + cx.tcx.crate_name(did.krate) == sym::libc && cx.tcx.def_path_str(did).ends_with(name.as_str()) } /// Returns the list of condition expressions and the list of blocks in a