Reduce String allocations in TransactionAspectSupport.methodIdentification() [SPR-14760] #19326
in some of my recent tests I noticed a rather "high" pressure on the heap coming from TransactionAspectSupport.methodIdentification(). (The image below shows the result of a 10 minute flight recording) for StringBuilder.append(String). Of course there are some more MBs (~200) allocated for the StringBuilder and the actual toString() calls - in case you need this data as well - just tell me.
As far as I understood the method it's "just" used for logging and monitoring - both of which are disabled in most situations, I'd say. Is this observation correct? Unfortunately, I didn't figure out yet how to implement my own version of TransactionAspectSupport inside a Spring-Boot app in order to workaround the problem at least for us, but that might be an issue for Boot after all.
Nonetheless, I attached a small PR that should at least force the compiler to concat the dot with a char instead of a String. Maybe this is the first step for 4.x until you can maybe come up with something smarter in 5.x.
Referenced from: pull request #1186
The text was updated successfully, but these errors were encountered:
Juergen Hoeller commented
I did a rather extensive pass across the codebase, changing all concatenations of single-char separators to single quotes. This certainly makes sense stylistically. However, I wonder whether this really makes a noticeable difference at runtime? Do you have actual profiling results for this?
In any case, for that method identification specifically, I've added a descriptor field to our
Christoph Dreis commented
I did again some 10 minute flight recordings today on our real application and noticed that there is - depending on how many transactions there are - up to 4-5GB pressure on the heap from the complete method. So thank you for resolving this.
Unfortunately, I just have a synthetic benchmark for you this evening to respond to your question if it's worthwile to switch from String to single-char concats.
Isolated string allocation test
While this is roughly a ~10% improvement in terms of throughput, I guess in the real world this will be barely noticeable for most applications - unless it's a really hot path or inside a synchronized block that could benefit from being faster. But after all it's execution time that could be spent somewhere else. In the end it could also be benefitial in terms of garbage collections, that one might save. If you're somehow memory restricted - like we are - you try to save everything you can ;-)
I additionally did a synthetic test that should mimic the new behaviour of the DefaultTransactionAttribute - e.g. caching this information instead of creating the string on every method call.
Caching allocated strings
This shows a factor of around 32, which for transaction heavy applications should make a difference.
Anyhow - I highly appreciate the effort on the complete codebase and more importantly on the initial subject. Thanks again!