Refactor -> StringUtils replace Optimization #33665
Conversation
The += 16 used before is too abstract. -If NewPattern is longer than 16, StringBuilder must be re -permitted again. -If NewPattern is shorter than 16, you will be assigned a memory to StringBuilder. For this reason, we will request a Code that is optimized. There is also a possibility that the length of the + NewPattern will be abnormally longer, To prevent the maximum size assignment, the maximum value is set to the maximum value of the int range.
spring-projects-issues
added
the
status: waiting-for-triage
| int newPatternLen = newPattern.length(); | ||
| int oldPatternLen = oldPattern.length(); | ||
| if (newPatternLen > oldPatternLen) { | ||
| capacity += Math.min(Integer.MAX_VALUE, newPatternLen - oldPatternLen); |
There was a problem hiding this comment.
Can you elaborate on why Math.min(Integer.MAX_VALUE, newPatternLen - oldPatternLen) is used here?
There was a problem hiding this comment.
I thought that there might be a case where the length of NewPattern is larger than integer.max_value.
In that case, the size of StringBuilder can become ridiculously large when initialized, so I set the size to integer.max_value as a minimum safety measure.
++ If the size of integer.max_value is too large, I think it would be fine to just make it 1024 or 2048.
There was a problem hiding this comment.
capacity += Math.max(16, newPatternLen - oldPatternLen);
I would like to modify the initial size to 16 as in the existing code,
but if the length of newPattern is larger, I would like to modify it to newPatternLen - oldPatternLen.
What do you think?
There was a problem hiding this comment.
I think this change is likely to make performance worse. This part is trying to extend the capacity of the builder if the new pattern is longer than the one to be replaced. Here, this change assumes that the pattern will be replaced only once. If the pattern is replaced multiple times, the builder will be expanded again.
I guess 16 is a simple heuristic given that we don't know in advance how many patterns will be replaced. If anything, we could consider expanding the builder by (newPatternLen - oldPatternLen) * 8 because we would guess the builder needs to grow several times the difference.
Looking at our usage pattern in Spring Framework, we're massively using this method for single chars replacements like StringUtils.replace(result, "\r", "\\r");.
In summary, I don't think we should merge this change.
|
I agree with @bclozel this change is likely to make the performance worse. Going forward, before submitting a change like this, please look for actual usages and share a benchmark that demonstrates the proposal improves the status quo. |
snicoll
added
status: declined
The += 16 used before is too abstract.
-If NewPattern is longer than 16, StringBuilder must be re -permitted again.
-If NewPattern is shorter than 16, you will be assigned a memory to StringBuilder.
For this reason, we request optimized code that allocates memory equal to the length of NewPattern.
There is also a possibility that the length of the
++ NewPattern will be abnormally longer, To prevent the maximum size assignment, the maximum value is set to the maximum value of the int range.