Bug #9064 com.mysql.jdbc.PreparedStatement.ParseInfo does unnecessary call to toCharArray

• Submitted: 9 Mar 2005 1:22
• Modified: 13 Feb 2006 23:07
• Reporter: [ name withheld ]
• Status: Closed
• Category: Connector/J
• Severity: S3 (Non-critical)
• Version: 3.1.11 and 3.1.12

[9 Mar 2005 1:22] [ name withheld ]

Description:
PreparedStatement.ParseInfo calls sql.toCharArray() twice in it's constructor. If the sql
string is very long, this results in unnecessary overhead (creating a new char array  and
copying the whole string).

How to repeat:
-

Suggested fix:
Call toCharArray() once.

[9 Mar 2005 1:30] [ name withheld ]

oops.

[27 Apr 2005 19:37] Mark Matthews

Fix is in 3.1.9.

[26 Jul 2005 17:15] Jason Winnebeck

The fix that I saw as of 3.1.10 doesn't fix the problem.  It moves the toCharArray outside
of the loop, which could be better, but still the call is unnecessary because there is no
reason to copy the string.  Instead why not use substring?  substring uses a
package-private constructor to construct a string that shares the buffer -- since String
is immutable, there is no reason to force a string copy with toCharArray.

[26 Jul 2005 17:54] Mark Matthews

It's just a pattern to not fall into the trap of String.substring() that causes memory
leaks (which is well known) _because_ of this sharing of a char[].

Also, the copy is relatively cheap, and prepared statements are generally created
infrequently as well. If we get some time we'll optimize this code, but it's not
generally in the critical path for performance of the JDBC driver.

[27 Jan 2006 4:05] [ name withheld ]

This bug was fixed in 3.1.10 and the call to toCharArray() was moved out of the loop. But
it's back inside the loop in 3.1.11 and 3.1.12.

[13 Feb 2006 23:07] Mark Matthews

Look again please, it's lazily instantiated.