Skip to content

perf: parse SQL to a single string, not a array of fragments#311

Merged
davecramer merged 1 commit intopgjdbc:masterfrom
Gordiychuk:statementParsing
Jun 28, 2015
Merged

perf: parse SQL to a single string, not a array of fragments#311
davecramer merged 1 commit intopgjdbc:masterfrom
Gordiychuk:statementParsing

Conversation

@vlsi
Copy link
Copy Markdown
Member

@vlsi vlsi commented Jun 11, 2015

This saves a bit of cycles when encoding the query to UTF8 (the whole query can be encoded at once)

I've updated both V2 and V3 queries.
?? -> ? replacing is folded into the parse process.

This saves a bit of cycles when encoding the query to UTF8 (the whole query can be encoded at once)
@vlsi vlsi force-pushed the statementParsing branch from 52b9b06 to 4797114 Compare June 15, 2015 08:40
@vlsi vlsi changed the title Parse SQL to a single string, not a array of fragments perf: parse SQL to a single string, not a array of fragments Jun 15, 2015
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like nativeSql.length() + 3 * bindPositions.length might save a StringBuilder resize in the common case? (Or 2 * bindPositions.length if we expect the number of bound parameters to be < 10 in almost all cases)

@davecramer davecramer merged commit 4797114 into pgjdbc:master Jun 28, 2015
vlsi added a commit to Gordiychuk/pgjdbc that referenced this pull request Jun 29, 2015
Rename toIntList to toIntArray, use better estimation for NativeQuery.toString result size.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants