Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #22028
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: String.substring in JDK 1.7.0_6+ |
| Date | 2013-02-02 15:31 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <kek7jh$fva$1@dont-email.me> (permalink) |
| References | (1 earlier) <510c9cea$0$80106$742ec2ed@news.sonic.net> <keid8j$2og$1@dont-email.me> <510d4249$0$80118$742ec2ed@news.sonic.net> <kejngo$lp1$1@dont-email.me> <510d972c$0$80186$742ec2ed@news.sonic.net> |
On 2/2/2013 2:46 PM, Kevin McMurtrie wrote:
> Some future JVMs do have JIT tricks to improve String performance. It's
> not clear how that would perform or what the side effects would be. One
The main think I'd like to see as a "trick" would be to spot when an
array is not accessed after a copy, thus negating the need for a copy.
String constructor:
public String( char[] chars ) {
this.buffer = Arrays.copyOf( chars, chars.length );
}
Usage:
public String someMethod() {
char[] myBuff = ... // a local variable
return new String( myBuff );
}
Spotting that the copy isn't needed because myBuff is local and can't be
accessed after the return is one obvious optimization.
If this type of analysis is very hard, I can see the original
implementation of StringBuilder would be advantageous. OTOH, it doesn't
look hard, and I'd bet there's a lot of situations where checking a
"copy-on-write bit" is a bigger performance hit.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:33 +0100
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 10:38 -0800
Re: String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:42 +0100
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 10:45 -0800
Re: String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:57 +0100
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 11:20 -0800
Re: String.substring in JDK 1.7.0_6+ Jan Burse <janburse@fastmail.fm> - 2013-02-01 20:34 +0100
Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-01 20:58 -0800
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 22:55 -0800
Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-02 08:43 -0800
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-02 10:56 -0800
Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-02 14:46 -0800
Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-02 15:31 -0800
Re: String.substring in JDK 1.7.0_6+ Robert Klemme <shortcutter@googlemail.com> - 2013-02-03 15:09 +0100
csiph-web