On 2023-11-28 Tu 20:58, Andrew Dunstan wrote:
On 2023-11-28 Tu 19:32, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
Cool, I took this and ran with it a bit. (See attached) Here are
comparative timings for 1000 iterations parsing most of the
information_schema.sql, all the way back to 9.3:
...
==== REL_15_STABLE ====
Time: 3372.491 ms (00:03.372)
==== REL_16_STABLE ====
Time: 1654.056 ms (00:01.654)
==== HEAD ====
Time: 1614.949 ms (00:01.615)
This is fairly repeatable.
These results astonished me, because I didn't recall us having done
anything that'd be likely to double the speed of the raw parser.
So I set out to replicate them, intending to bisect to find where
the change happened. And ... I can't replicate them. What I got
is essentially level performance from HEAD back to d10b19e22
(Stamp HEAD as 14devel):
HEAD: 3742.544 ms
d31d30973a (16 stamp): 3871.441 ms
596b5af1d (15 stamp): 3759.319 ms
d10b19e22 (14 stamp): 3730.834 ms
The run-to-run variation is a couple percent, which means that
these differences are down in the noise. This is using your
test code from github (but with 5000 iterations not 1000).
Builds are pretty vanilla with asserts off, on an M1 MacBook Pro.
The bison version might matter here: it's 3.8.2 from MacPorts.
I wondered if you'd tested assert-enabled builds, but there
doesn't seem to be much variation with that turned on either.
So I'm now a bit baffled. Can you provide more color on what
your test setup is?
*sigh* yes, you're right. I inadvertently used a setup that used meson
for building REL16_STABLE and HEAD. When I switch it to autoconf I get
results that are similar to the earlier branches:
==== REL_16_STABLE ====
Time: 3401.625 ms (00:03.402)
==== HEAD ====
Time: 3419.088 ms (00:03.419)
It's not clear to me why that should be. I didn't have assertions
enabled anywhere. It's the same version of bison, same compiler
throughout. Maybe meson sets a higher level of optimization? It
shouldn't really matter, ISTM.
OK, with completely vanilla autoconf builds, doing 5000 iterations, here
are the timings I get, including a test with Amit's latest published
patches (with a small fixup due to bitrot).
Essentially, with the patches applied it's very slightly slower than
master, about the same as release 16, faster than everything earlier.
And we hope to improve the grammar impact of the JSON_TABLE piece before
we're done.
==== REL_11_STABLE ====
Time: 10381.814 ms (00:10.382)
==== REL_12_STABLE ====
Time: 8151.213 ms (00:08.151)
==== REL_13_STABLE ====
Time: 7774.034 ms (00:07.774)
==== REL_14_STABLE ====
Time: 7911.005 ms (00:07.911)
==== REL_15_STABLE ====
Time: 7868.483 ms (00:07.868)
==== REL_16_STABLE ====
Time: 7729.359 ms (00:07.729)
==== master ====
Time: 7615.815 ms (00:07.616)
==== sqljson ====
Time: 7715.652 ms (00:07.716)
Bottom line: I don't think grammar slowdown is a reason to be concerned
about these patches.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
