Improve performance of some string operations [SPR-16293]

[spring-projects-issues]

Christoph Dreis opened SPR-16293 and commented

Hi,

while looking into some Spring-Boot performance improvements, I noticed several opportunities to speedup String operations in the Spring-Framework as well. Mostly, but not limited to excessive substring calls.

For the above case I did some JMH benchmarks:

Benchmark-Code

    @Benchmark
    public String testNew(TestState testState) {
        return StringUtils.uncapitalize(testState.originalString);
    }

    @Benchmark
    public String testOld(TestState testState) {
	return testState.originalString.substring(0, 1).toLowerCase() + testState.originalString.substring(1);
    }

Benchmark-Results

Benchmark.testNew                                   thrpt   10  270068983,325 ± 8686263,066   ops/s
Benchmark.testNew:·gc.alloc.rate                    thrpt   10         ? 10??                MB/sec
Benchmark.testNew:·gc.alloc.rate.norm               thrpt   10         ? 10??                  B/op
Benchmark.testNew:·gc.count                         thrpt   10            ? 0                counts
Benchmark.testOld                                   thrpt   10   15616764,260 ±  699591,770   ops/s
Benchmark.testOld:·gc.alloc.rate                    thrpt   10       3653,894 ±     164,045  MB/sec
Benchmark.testOld:·gc.alloc.rate.norm               thrpt   10        368,000 ±       0,001    B/op
Benchmark.testOld:·gc.churn.PS_Eden_Space           thrpt   10       3721,582 ±     265,154  MB/sec
Benchmark.testOld:·gc.churn.PS_Eden_Space.norm      thrpt   10        374,905 ±      24,713    B/op
Benchmark.testOld:·gc.churn.PS_Survivor_Space       thrpt   10          0,169 ±       0,069  MB/sec
Benchmark.testOld:·gc.churn.PS_Survivor_Space.norm  thrpt   10          0,017 ±       0,007    B/op
Benchmark.testOld:·gc.count                         thrpt   10        151,000                counts
Benchmark.testOld:·gc.time                          thrpt   10         80,000                    ms

Please note that this shows a case, where nothing has to be done. The case in which we really have to replace something still shows an improvement-factor of 3 to 4, though.

I hope the attached PR gets accepted and possibly merged back into 4.3.

Cheers,
Christoph

---

Affects: 4.3.13

Referenced from: pull request #1622, and commits 260ebec, d7959ed, 9d42184

Backported to: 4.3.14

[spring-projects-issues]

Juergen Hoeller commented

Looks good to me! Thanks for raising this - indeed a common source of unnecessary allocations.

Merged into master for 5.0.3 now, and I'll include it in my upcoming bunch of backports to 4.3.14.