From: Qerogram <qerogram@naver.com>
To: acme@kernel.org, namhyung@kernel.org
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
irogers@google.com, Qerogram <qerogram@naver.com>
Subject: [PATCH perf-tools-next] perf list: Avoid repeated strlen when escaping JSON strings
Date: Thu, 10 Sep 2026 21:38:39 +0900 [thread overview]
Message-ID: <20260910123839.72285-1-qerogram@naver.com> (raw)
The %S conversion in fix_escape_fprintf() calls strlen(s) in the loop
condition while escaping each character. GCC 14.2.0 retains this call
inside the loop in a normal DEBUG=0 (-O3) perf build, repeatedly scanning
the whole string.
Test the current character for NUL instead. This processes the same bytes
without rescanning the string. Escaping and buffer growth are unchanged.
Full-command wall-clock measurements on an Apple M5 Pro host running an
aarch64 Linux container with GCC 14.2.0 and glibc 2.41 gave these medians:
perf list --json metrics Before (ms) After (ms)
Default catalog 0.5969 0.5855
PERF_CPUID=0x00000000410fd830 0.7818 0.7033
Each workload used 50 randomized before/after pairs. Each sample averages
the time per invocation across five fresh processes, with stdout sent to
/dev/null and no single-CPU pinning. PERF_CPUID selects the shipped V3
catalog on the same host; these are not measurements on V3 hardware. The
measurements include process startup and do not establish a gain on other
machines or perf commands.
These observations come from one short run. Relinking also changes code
layout: .text grows from 2,013,172 to 2,017,236 bytes in this build. The
timings do not isolate scan removal from the changed layout.
The existing list shell test passes for both binaries. Source-extracted
functions linked to perf's strbuf implementation pass 906 equivalence
cases with ASan and UBSan. Full-command outputs are byte-identical.
Codex assisted with identifying the redundant scan, preparing the change,
and running the comparisons.
Assisted-by: LLM
Signed-off-by: Qerogram <qerogram@naver.com>
---
tools/perf/builtin-list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 50f69c2c0d51..4118424cb364 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -325,7 +325,7 @@ static void fix_escape_fprintf(FILE *fp, struct strbuf *buf, const char *fmt, ..
case 'S': {
const char *s = va_arg(args, const char*);
- for (size_t s_pos = 0; s_pos < strlen(s); s_pos++) {
+ for (size_t s_pos = 0; s[s_pos] != '\0'; s_pos++) {
switch (s[s_pos]) {
case '\n':
strbuf_addstr(buf, "\\n");
--
2.55.0
next reply other threads:[~2026-09-10 12:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 12:38 Qerogram [this message]
2026-09-13 21:45 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260910123839.72285-1-qerogram@naver.com \
--to=qerogram@naver.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®