RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks (original) (raw)
Martin Buchholz martinrb at google.com
Fri May 10 18:34:07 UTC 2013
- Previous message: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks
- Next message: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, May 10, 2013 at 10:36 AM, Mike Duigou <mike.duigou at oracle.com>wrote:
The implementation looks OK to me. I like Peter's suggestion of caching the char[] rather than string.
I do wish that the cache could be in a soft reference but understand that there are tradeoffs to doing so. I am worried about leaks with this implementation. Another possibility, to go totally nuts, is to consider implementing a form of copy-on-write-following-toString. This would be the exact opposite of "minimal set of changes to address this specific problem" and probably not wise to attempt for Java 8. Just as an FYI, this issue has in-flight conflicts with Martin's ongoing CharSequence.getChars patch.
I agree with Alan about the cringe factor, and I prefer the old implementation. But it's understandable and not too terrible for real world users, because no one outside of unrealistic benchmarks should be making heavy use of StringBuffer.
And: Yes, I will need to update my own changes to StringB*.
- Previous message: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks
- Next message: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]