From: Philip H. <phi...@in...> - 2009-01-18 21:27:29
|
On 18 Jan, 2009, at 12:16 am, Philip Hudson wrote: > On 17 Jan, 2009, at 8:17 pm, Erik Huelsmann wrote: > >>> I propose to replace FastStringBuffer wherever it occurs outside >>> of a >>> loop with the '+' and '+=' String concatenation operators and/or >>> Java >>> 5's String.format(). This will shrink and simplify the code. >> >> What I'm wondering is whether this really brings us something: I >> think >> most of our string-creation is outside of the main line of execution, >> such as generating text for error messages, isn't it? If that's true, >> the potential gain of speed isn't too big. Ofcourse, there still >> remains the (potential) gain of readability of code. > >>> With judicious use of 'final' declarations of String parameters and >>> variables we want to concatenate, we can achieve some genuine String >>> concatenation optimizations with a pretty good guarantee of forward >>> compatibility. The compiler is able to treat such final String >>> variables as String constants, and emits hyper-efficient bytecode >>> when concatenating them with other String constants and literals. >> >> One of the things which make me cautious about this change is: We'll >> be able to axe 1 class (maybe), but we'll need to change virtually >> every file in the project, right? I mean, the churn to achieve this >> change is huge or at least, it is my gut feeling it is. >> >> Do you think that the cost of creating this patch outweighs the risk >> (changing code means risk of destablization) and benefit? Or maybe >> you >> have some facts for us which will enable us to take an informed >> decision? And so, herewith: |