Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8120

Re: StringBuilder

Show all headers | View raw

Wanja Gayk wrote:
> ar...@vajhoej.dk says...
> 
>>>> It should be in any Java book above beginners level.
>>>
>>> Like other ancient performance-practices that have been obsoleted by
>>> today's compilers?
>> 
>> No.
>> 
>> What we are talking about is the "+=" part and that part is
>> still relevant for todays compilers.
> 
> And "still" is the keyword. The question remains: For how long will this 
> hold true?

You said "today's compilers".

>> Actually JB's example use = but to be equivalent to the first code
>> the it need to be +=.
>> 
>> And besides what he mention as reasons there are also
>> the 100 new strings.
> 
> So what's the problem with these? before answering, just have a look at 
> this: 
> http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

That tells part of the story, but extra objects still cause both memory and time overhead.  Time comes from GC cycles that kick in because you were profligate.
...[snip] ...
> 
> Nope, I'm arguing that:
> 
> String x="";
> for(String s : strings){
>  x+=s;
> }
> 
> or 
> 
> String x="";
> for(String s : strings){
>  x=x+s;
> }
> 
> Is simple pattern that could be detected by tomorrows JIT-compilers and 

But you changed your argument.  You _were_ speaking of "today's compilers".  Now suddenly you're speaking of "tomorrows [sic] JIT-compilers".

Besides shifting your ground, you have weakened your argument.  It's one thing to program to allow "tomorrow's compilers" to further optimize your code, it's quite another to program to *require* "tomorrow's compilers" to further optimize your code.

You don't know for a fact that "tomorrow's compilers" will ever optimize across multiple lines of 'String' concatenation.

As you say, they "could be" able to do that; you just cannot aver that they will be able to do that.

But of course, that's only now that you've moved the discussion from "today's compilers" as you first said, to "tomorrow's compilers" as you now wish to discuss.

> transformed into:
> 
> StringBuilder b = new StringBuilder();
> for(String s : strings){
>  b.append(s);
> }
> String x = b.toString();
> 
> But I don't think any compiler programmer would care to detect this 
> pattern:
> 
> StringBuffer b = new StringBuffer ();
> for(String s : strings){
>  b.append(s);
> }
> String x = b.toString();
> 
> Just to transform it into the the StringBuilder-variant.

That would likely be incorrect anyway, since the semantics differ.  Of course, "tomorrow's JIT compiler" could figure out that there's no thread leak, so it "could be" able to do it.  Maybe.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: StringBuilder Wanja Gayk <brixomatic@yahoo.com> - 2011-09-11 16:35 +0200
  Re: StringBuilder Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 16:48 -0400
    Re: StringBuilder Wanja Gayk <brixomatic@yahoo.com> - 2011-09-17 02:54 +0200
      Re: StringBuilder Roedy Green <see_website@mindprod.com.invalid> - 2011-09-17 00:27 -0700
      Re: StringBuilder Lew <lewbloch@gmail.com> - 2011-09-18 01:42 -0700
        Re: StringBuilder Wanja Gayk <brixomatic@yahoo.com> - 2011-09-19 00:59 +0200
          Re: StringBuilder Roedy Green <see_website@mindprod.com.invalid> - 2011-09-19 05:07 -0700
            Re: StringBuilder Jeff Higgins <jeff@invalid.invalid> - 2011-09-19 11:38 -0400

csiph-web