Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
1.1.8
-
None
-
Linux
Description
After upgrading from 1.1.7 to 1.1.8, I noticed a performance decrease. The CPU Sampler in VisualVM pointed to MySQLParameterizedQuery.toSQL2() being the issue.
I modified this method to use a StringBuilder instead of += which seems to have addressed the issue.
Updated Code:
private String toSQL2() throws UnsupportedEncodingException {
if(queryPartsArray.length == 0)
StringBuilder sb = new StringBuilder(new String(queryPartsArray[0], "UTF-8"));
for(int i = 1; i<queryPartsArray.length; i++)
{ sb.append(parameters[i-1]); if(queryPartsArray[i].length != 0) sb.append(new String(queryPartsArray[i], "UTF-8")); } return sb.toString();
}
Attachments
Activity
same as Vladislav, each query implementation has a write method based on byte arrays. There is no need for transformation to have the write size.
merge https://github.com/MariaDB/mariadb-connector-j/commit/a163bdbb0d01123095634593047873273fb2bb9f
Gave it a try here
https://github.com/vaintroub/mariadb-connector-j/commit/59f3d68c1bbd32936e631b9e533c31f45d5ec770
It turns out a bit more complicated with max_allowed_packet over 16MB, where query splits into multiple packets. In that case, terminate the connection whenever max_allowed_packet would overflow seems ok. also removed methods that materialize prepared statement toSQL() and toByteArray()as string rsp bytes in my patch, hope this is ok 
The commit https://github.com/MariaDB/mariadb-connector-j/commit/8e507c416ef17b3b556b16d4cbff0bca59ebd233 was a mistake.
Constructing query as string just to get its UTF8 length is a wrong approach