Best way to do this?
in [Java Help]
|
Prev: Const correctness (was Re: Oppinion on 'least priviledge','const correctness', etc.)
Next: How to remotely construct a remote object with RMI
From: harryajh on 23 Jul 2010 03:43 On Jul 23, 2:17 am, Lew <no...(a)lewscanon.com> wrote: > harryajh writes: > >> A bit lost as to what's the best/efficient way to do this, should I > >> use a StringBuffer every time? would it be garbage collected? - any > >> other ideas? > Jim Janney wrote: > > However, there's another mistake that I can't bring myself to ignore, > > so: no, using a String to hold the field's value is not wrong, and > > using a StringBuilder will not help you. > > It's even worse than that. He asked about using a StringBuffer. > > -- > Lew Many thanks for all replies to this, when I said it was "vastly cut down" I didn't realise how much I had (there's a lot more that perhaps I should have left in!), which seemed to cause a lot of confusion, sorry for that chaps My main point was the "String propName = rs.getString(2);" line, thinking it was creating a object each time but actually thinking about it the String has already been created by in the resultset and therefore I think I'm right in saying this will not be a problem as propName will just point to it? cheers
From: Lew on 23 Jul 2010 08:41 harryajh wrote: >> -- >> Lew Please don't quote sigs. > My main point was the "String propName = rs.getString(2);" line, > thinking it was creating a object each time but actually thinking Why would that have been a problem? > about it the String has already been created by in the resultset and > therefore I think I'm right in saying this will not be a problem as > propName will just point to it? 'propName' does just point to it. There is a new 'String' allocated for each string column of each row of each query. You seem to be concerned with really microscopic issues. What is the real risk that you seek to address and why? -- Lew
From: Alan Gutierrez on 23 Jul 2010 09:22 Lew wrote: > harryajh wrote: >>> -- >>> Lew > > Please don't quote sigs. > >> My main point was the "String propName = rs.getString(2);" line, >> thinking it was creating a object each time but actually thinking > > Why would that have been a problem? > >> about it the String has already been created by in the resultset and >> therefore I think I'm right in saying this will not be a problem as >> propName will just point to it? > > 'propName' does just point to it. There is a new 'String' allocated for > each string column of each row of each query. > > You seem to be concerned with really microscopic issues. What is the > real risk that you seek to address and why? I second. Did you have a look at that Jeff Atword article I linked to? Did you draw anything from it? Optimization should always be guided by profiling of some sort. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Jim Janney on 23 Jul 2010 10:24
harryajh <harryreg_uk(a)yahoo.co.uk> writes: > On Jul 23, 2:17 am, Lew <no...(a)lewscanon.com> wrote: >> harryajh writes: >> >> A bit lost as to what's the best/efficient way to do this, should I >> >> use a StringBuffer every time? would it be garbage collected? - any >> >> other ideas? >> Jim Janney wrote: >> > However, there's another mistake that I can't bring myself to ignore, >> > so: no, using a String to hold the field's value is not wrong, and >> > using a StringBuilder will not help you. >> >> It's even worse than that. He asked about using a StringBuffer. >> >> -- >> Lew > > Many thanks for all replies to this, when I said it was "vastly cut > down" I didn't realise how much I had (there's a lot more that perhaps > I should have left in!), which seemed to cause a lot of confusion, > sorry for that chaps > > My main point was the "String propName = rs.getString(2);" line, > thinking it was creating a object each time but actually thinking > about it the String has already been created by in the resultset and > therefore I think I'm right in saying this will not be a problem as > propName will just point to it? Yes, exactly. -- Jim Janney |