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

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

[9 Mar 2005 0: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 0:30] [ name withheld ]

oops.

[27 Apr 2005 17:37] Mark Matthews

Fix is in 3.1.9.

[26 Jul 2005 15: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 15: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 3: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 22:07] Mark Matthews

Look again please, it's lazily instantiated.