Re: remaining sql/json patches

On 2023-11-28 Tu 20:58, Andrew Dunstan wrote:
>
> On 2023-11-28 Tu 19:32, Tom Lane wrote:
>> Andrew Dunstan <andrew@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