Vadim Nasardinov wrote:
> I assume you're talking about
> org/postgresql/jdbc2/AbstractJdbc2Statement.java which has this piece
> of code (slightly reformatted to fit on a 80-column page):
[snip]
> This does appear to be optimized for reading smallish chunks of text.
> If the character source behind the Reader is sufficiently large, I
> believe we'd be better off building up a StringBuffer rather than a
> character array. Something like this:
>
> if (connection.haveMinimumCompatibleVersion("7.2")) {
> StringBuffer sb = new StringBuffer(length);
> BufferedReader br = new BufferedReader(x);
> try {
> while(true) {
> String chunk = br.readLine();
> if (chunk == null) { break; }
> else {sb.append(chunk); }
> }
> } catch (IOException l_ioe) {
> throw new PSQLException(GT.tr("Provided Reader failed."),
> PSQLState.UNEXPECTED_ERROR, l_ioe);
> }
> setString(i, sb.toString());
> }
>
> The reason this is better is because
>
> (a) the String(char[],int,int) constructor always defensively copies
> the passed in character array. So, as you point out, if you
> pass in a 10-million-character array, a new 10-million character
> array will be allocated.
>
> (b) in contrast, if you construct a String from a StringBuffer, they
> can share the underlying character array:
> http://www.google.com/search?q=Heinz+Kabutz+StringBuffer+Issue+068&btnI
This is indeed part of the code I was talking about. And indeed a
StringBuffer is already a definate improvement.
However, the setString() method will also cause the data to be duplicated
when escapeString() is called. A version of escapeString() which works
on a StringBuffer would be another improvement in my opinion, saving
(if the allocated StringBuffer is made a bit larger to allow for the
escaping), in most cases another allocation of the whole string.
Greetings,
Sebastiaan van Erk
