Avoid creating byte[] multiple times in StringHttpMessageConverter

[brucelwl]

When calculating the ContentLength and writing data to the OutputStream in StringHttpMessageConverter, calling str.getBytes(charset) repeatedly will result in unnecessary array objects occupying memory

spring-framework/spring-web/src/main/java/org/springframework/http/converter/StringHttpMessageConverter.java

Lines 103 to 106 in 09917fa

	protected Long getContentLength(String str, @Nullable MediaType contentType) {
	Charset charset = getContentTypeCharset(contentType);
	return (long) str.getBytes(charset).length;
	}

spring-framework/spring-web/src/main/java/org/springframework/http/converter/StringHttpMessageConverter.java

Lines 122 to 129 in 09917fa

	protected void writeInternal(String str, HttpOutputMessage outputMessage) throws IOException {
	HttpHeaders headers = outputMessage.getHeaders();
	if (this.writeAcceptCharset && headers.get(HttpHeaders.ACCEPT_CHARSET) == null) {
	headers.setAcceptCharset(getAcceptedCharsets());
	}
	Charset charset = getContentTypeCharset(headers.getContentType());
	StreamUtils.copy(str, charset, outputMessage.getBody());
	}

[bclozel]

Superseded by #35276

We can reopen this issue if we can find a way to improve performance without failing the correct behavior.

[brucelwl]

@bclozel I have identified the reason for the build failure, but my submission signature was not carried.
It has now been fixed. see #35280 ,
Please open this issue,
Thanks

[kilink]

I've looked into ways around this in the past, one easy approach is to special case ASCII Strings when the target Charset is ASCII or an ASCII superset (like UTF-8). Proof of concept here: #35290.

UTF-8 length can be completely handled without allocating the byte array if we added a utility like the one in Guava.

For ASCII and ISO_8859_1, I believe we can actually just use codePoints() to calculate the length and handle the case of surrogate pairs if we really wanted to.

IMO it would probably be best to decide whether it's worth adding a utility for UTF-8 length calculation specifically, and special case that, since I imagine it's the most commonly used encoding.

Anyway, the only way I can see to preserve backwards compatibility and also avoid the extra allocation is to special case certain character sets and just do the calculations ourselves.

[rstoyanchev]

@kilink thanks for the suggestion, but it becomes then a trade-off between CPU vs memory allocation. Also optimized for the ascii case, but as a side effect less optimized for non-ascii which would require both approaches.

I think we can try to bring closer together setting the content-length and the actual write, or at least make it possible where an optimization can be made.

We could experiment with StringHttpMessageConverter opting out of content-length writing either by returning null from getContentLength or by having content-length header logic extracted into a protected method, and then setting it from within writeInternal.