While profiling some software that makes heavy use of prepared statements and SQLite, I noticed that each call to java.sql.Connection#prepareStatement(java.lang.String) ended up compiling a regex pattern as part of org.sqlite.core.CoreStatement.<init>(SQLiteConnection) construction. This appears to be a recent addition as part of https://github.com/xerial/sqlite-jdbc/pull/1056 with example call trace showing up as over 75% of total allocations in JFR:
Because JDK Pattern instances are immutable and thread-safe, we can compile the regex on CoreStatement class load to a static field for reuse, and adjust the regex to avoid additional possible allocations from trimming and converting the SQL to lower case, as well as use non-capturing groups to avoid Pattern#matcher allocating the int[] arrays associated with capture groups.
gotson
commented
8 months ago
While profiling some software that makes heavy use of prepared statements and SQLite, I noticed that each call to
java.sql.Connection#prepareStatement(java.lang.String)ended up compiling a regex pattern as part oforg.sqlite.core.CoreStatement.<init>(SQLiteConnection)construction. This appears to be a recent addition as part of https://github.com/xerial/sqlite-jdbc/pull/1056 with example call trace showing up as over 75% of total allocations in JFR:Because JDK
Patterninstances are immutable and thread-safe, we can compile the regex onCoreStatementclass load to a static field for reuse, and adjust the regex to avoid additional possible allocations from trimming and converting the SQL to lower case, as well as use non-capturing groups to avoidPattern#matcherallocating theint[]arrays associated with capture groups.