[performance-profiler] Optimize add_locale offset formatting in Format hot path

[github-actions]

Hot Path

addLocale.Format in libbeat/processors/add_locale/add_locale.go:101-125 is on the benchmarked path for BenchmarkConstruct and currently spends avoidable time/allocations in offset-string formatting.

Profiling Data

Before:

go test ./libbeat/processors/add_locale -run '^$' -bench 'BenchmarkConstruct$' -benchmem -count=5

BenchmarkConstruct-4   3204235   362.2 ns/op   104 B/op   4 allocs/op
BenchmarkConstruct-4   3529683   382.7 ns/op   104 B/op   4 allocs/op
BenchmarkConstruct-4   3214898   349.1 ns/op   104 B/op   4 allocs/op
BenchmarkConstruct-4   3503536   352.6 ns/op   104 B/op   4 allocs/op
BenchmarkConstruct-4   3225561   362.3 ns/op   104 B/op   4 allocs/op

Proposed Change

Replace fmt.Sprintf("%s%02d:%02d", sign, h, m) in addLocale.Format with fixed-width byte-buffer formatting:

- sign := "+"
+ sign := byte('+')
  if offset < 0 {
-   sign = "-"
+   sign = '-'
    offset *= -1
  }
  h := offset / hour
  m := (offset - (h * hour)) / min
- ft = fmt.Sprintf("%s%02d:%02d", sign, h, m)
+ var buf [6]byte
+ buf[0] = sign
+ buf[1] = byte('0' + h/10)
+ buf[2] = byte('0' + h%10)
+ buf[3] = ':'
+ buf[4] = byte('0' + m/10)
+ buf[5] = byte('0' + m%10)
+ ft = string(buf[:])

Results

After:

go test ./libbeat/processors/add_locale -run '^$' -bench 'BenchmarkConstruct$' -benchmem -count=5

BenchmarkConstruct-4   5605015   200.5 ns/op   88 B/op   3 allocs/op
BenchmarkConstruct-4   5342575   209.8 ns/op   88 B/op   3 allocs/op
BenchmarkConstruct-4   5872142   198.6 ns/op   88 B/op   3 allocs/op
BenchmarkConstruct-4   5794014   199.4 ns/op   88 B/op   3 allocs/op
BenchmarkConstruct-4   6136920   196.1 ns/op   88 B/op   3 allocs/op

Improvement:

• Time: 361.78 ns/op → 200.88 ns/op (44.48% faster)
• Memory: 104 B/op → 88 B/op (15.38% lower)
• Allocations: 4 → 3 allocs/op (25% fewer allocations)

Verification

• go test ./libbeat/processors/add_locale -run '^$' -bench 'BenchmarkConstruct$' -benchmem -count=5 (before/after with same command)
• go test ./libbeat/processors/add_locale (passes)
• Behavior preserved: change only affects string construction mechanics for the same ±HH:MM output format.

Evidence

• Hot-path code: libbeat/processors/add_locale/add_locale.go:101-125
• Duplicate checks:
  • /tmp/previous-findings.json: no existing open finding for add_locale/BenchmarkConstruct
  • Open issue searches returned no matches:
    • repo:elastic/beats is:issue is:open performance-profiler add_locale BenchmarkConstruct
    • repo:elastic/beats is:issue is:open add_locale timezone offset performance

Note

🔒 Integrity filter blocked 9 items

The following items were blocked because they don't meet the GitHub integrity level.

• #33512 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #30073 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #49814 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #35229 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #43660 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #47666 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #30677 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #14917 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #44780 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: Performance Profiler

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

• expires on May 1, 2026, 2:49 PM UTC

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[mauri870]

/ai Absolute worthwhile optimization! But I think there is an even bigger lever. We can cache the timezone string and only refresh it if we detect changes (like DST or manual). We might be able to use sync.Once, but that might be too agressive. Please do this profiling run again with the proposed approach for comparison.

[github-actions]

Implemented and profiled the cache-on-change approach locally, and it’s a clear win.

I tested a variant that caches the formatted timezone string in the processor instance and only recomputes when (zone, offset) changes (libbeat/processors/add_locale/add_locale.go:33-44, :111-133). The refresh path is explicit and change-driven, not sync.Once (libbeat/processors/add_locale/add_locale.go:123-132).

Command used (same shape as before):
go test ./libbeat/processors/add_locale -run '^$' -bench '^BenchmarkConstruct$' -benchmem -count=8

Results on this runner:

Variant	ns/op (avg)	B/op	allocs/op
current mainline code	410.45	104	4
cached timezone string (refresh on change)	190.86	80	2

Delta vs current mainline: 53.5% faster, 23.1% less memory, 50% fewer allocs.

For extra context against the earlier formatting-only optimization reported in this issue (200.88 ns/op, 88 B/op, 3 allocs/op), this cache-based variant is still better: about 5.0% faster, 9.1% lower B/op, and 1 fewer allocation/op.

I also added a focused cache-refresh test to verify updates when the offset changes (libbeat/processors/add_locale/add_locale_test.go:88-102).

---

What is this? | From workflow: Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[mauri870]

/ai Looking good! Please open a PR with the proposed cache-on-change approach, including benchmarks and test results

[github-actions]

Opened a PR with the cache-on-change implementation for add_locale timezone formatting.

Implemented changes:

• Added cached timezone string in processor state, refreshed only when (zone, offset) changes.
• Switched New to return a pointer processor instance so cache persists across Run calls.
• Added focused test TestTimezoneFormatCacheRefreshOnChange.
• Added changelog fragment for libbeat enhancement.

Benchmark command:
go test ./libbeat/processors/add_locale -run '^$' -bench '^BenchmarkConstruct$' -benchmem -count=8

Measured on this branch:

• BenchmarkConstruct: 182.54 ns/op avg, 80 B/op, 2 allocs/op

Reference baseline from issue thread:

• 410.45 ns/op, 104 B/op, 4 allocs/op

Delta vs baseline: ~55.5% faster, ~23.1% lower memory, 50% fewer allocations.

Test command:
go test ./libbeat/processors/add_locale -run Test -count=1

---

What is this? | From workflow: Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.