Commit 63cf1e3
committed
Optimize AbstractStatementParser.statementStartsWith
I found this was taking ~25% of the CPU of pgadapter when running
the TPCC benchmark loader, which seems to generate very large DMLs.
Previously, it would call split() over the whole string with
a limit. Now, it uses Guava's lazy splitter so that it doesn't
have to copy the remainder of the string following the second
match.
For whatever reason, it seems like the previous implementation
was doing something much more expensive than just copying the
tail. For 100kb long query text, this new implementation is
1600x faster. For short queries it's only a few times faster.
Before:
Benchmark Mode Cnt Score Error Units
StatementParserBenchmark.isQueryTest thrpt 5 1461962.835 ± 340237.573 ops/s
StatementParserBenchmark.longQueryTest thrpt 5 2873.150 ± 490.611 ops/s
After:
Benchmark Mode Cnt Score Error Units
StatementParserBenchmark.isQueryTest thrpt 5 4765215.378 ± 132661.232 ops/s
StatementParserBenchmark.longQueryTest thrpt 5 4671884.683 ± 486566.506 ops/s1 parent 27f0f15 commit 63cf1e3
File tree
1 file changed
+16
-10
lines changed- google-cloud-spanner/src/main/java/com/google/cloud/spanner/connection
1 file changed
+16
-10
lines changedLines changed: 16 additions & 10 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
31 | 31 | | |
32 | 32 | | |
33 | 33 | | |
| 34 | + | |
34 | 35 | | |
35 | 36 | | |
36 | 37 | | |
| |||
41 | 42 | | |
42 | 43 | | |
43 | 44 | | |
| 45 | + | |
44 | 46 | | |
45 | 47 | | |
46 | 48 | | |
| |||
614 | 616 | | |
615 | 617 | | |
616 | 618 | | |
617 | | - | |
618 | | - | |
619 | | - | |
620 | | - | |
621 | | - | |
622 | | - | |
623 | | - | |
624 | | - | |
625 | | - | |
626 | | - | |
| 619 | + | |
| 620 | + | |
| 621 | + | |
| 622 | + | |
| 623 | + | |
| 624 | + | |
| 625 | + | |
| 626 | + | |
| 627 | + | |
| 628 | + | |
| 629 | + | |
| 630 | + | |
| 631 | + | |
| 632 | + | |
627 | 633 | | |
628 | 634 | | |
629 | 635 | | |
| |||
0 commit comments