Skip to content

Conversation

@aalsanie
Copy link

ContextPairs builds nested pairs by splitting each name on ".". The current implementation uses String.split("\\."), which is regex-based and allocates an array and list per name.

Here I replaced the regex split with a manual dot delimited scan that reduces allocations and avoids regex overhead while preserving existing behavior.

A test has been added.

@spring-projects-issuesspring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 28, 2026
ContextPairs currently uses String.split("\\.") to expand nested names. String.split is regex-based and allocates per call. Replace it with a manual dot-delimited scan to reduce allocations and CPU overhead while preserving existing behavior. Signed-off-by: Ahmad Al-Sanie ahmad.alsanie@hotmail.com Signed-off-by: aalsanie <ahmad.alsanie@hotmail.com>
@wilkinsona
Copy link
Member

Thanks for the PR. Unfortunately, I'm not sure that we should merge it as it adds a significant amount of complexity. To consider merging it, I think we'd need to see evidence that the change makes a notable difference to real-world performance.

@wilkinsonawilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Jan 28, 2026
@aalsanie
Copy link
Author

@wilkinsona Thanks for the feedback, I went and isolated both implementations into the same class and executed them under identical JVM conditions.

java SplitPerf

regex: 664 ms (66.42357 ns/op) manual: 478 ms (47.80414 ns/op) blackhole=0 

java -XX:StartFlightRecording=filename=split.jfr,settings=profile -cp . SplitPerf

regex: 706 ms (70.6994 ns/op) manual: 487 ms (48.79678 ns/op) blackhole=0 

Running 10M iterations shows a consistent ~30% reduction in execution time,, the reduced allocation rate also lowers GC pressure.

allocationmethod profiling

@spring-projects-issuesspring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 28, 2026
@wilkinsona
Copy link
Member

Thanks. That's not quite what I meant by real-world and is more of a micro benchmark. To justify the extra complexity, I think we'd need to see an improvement in the performance of structured logging.

@wilkinsonawilkinsona added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Jan 28, 2026
@aalsanie
Copy link
Author

Fair enough, I’ll put together a small boot app with structured logging end-to-end and compare baseline.

@spring-projects-issuesspring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 28, 2026
@wilkinsonawilkinsona added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Jan 28, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-feedbackWe need additional information before we can continuestatus: waiting-for-triageAn issue we've not yet triaged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@aalsanie@wilkinsona@spring-projects-issues