Re: remaining sql/json patches

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.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com