On Thu, Nov 16, 2023 at 2:11 AM Andres Freund <andres@anarazel.de> wrote:
> On 2023-11-15 22:00:41 +0900, Amit Langote wrote:
> > > This causes a nontrivial increase in the size of the parser (~5% in an
> > > optimized build here), I wonder if we can do better.
> >
> > Hmm, sorry if I sound ignorant but what do you mean by the parser here?
>
> gram.o, in an optimized build.
>
> > I can see that the byte-size of gram.o increases by 1.66% after the
> > above additions (1.72% with previous versions).
>
> I'm not sure anymore how I measured it, but if you just looked at the total
> file size, that might not show the full gain, because of debug symbols
> etc. You can use the size command to look at just the code and data size.
$ size /tmp/gram.*
text data bss dec hex filename
661808 0 0 661808 a1930 /tmp/gram.o.unpatched
672800 0 0 672800 a4420 /tmp/gram.o.patched
That's still a 1.66% increase in the code size:
(672800 - 661808) / 661808 % = 1.66
As for gram.c, the increase is a bit larger:
$ ll /tmp/gram.*
-rw-rw-r--. 1 amit amit 2605925 Nov 16 16:18 /tmp/gram.c.unpatched
-rw-rw-r--. 1 amit amit 2709422 Nov 16 16:22 /tmp/gram.c.patched
(2709422 - 2605925) / 2605925 % = 3.97
> > I've also checked
> > using log_parser_stats that there isn't much slowdown in the
> > raw-parsing speed.
>
> What does "isn't much slowdown" mean in numbers?
Sure, the benchmark I used measured the elapsed time (using
log_parser_stats) of parsing a simple select statement (*) averaged
over 10000 repetitions of the same query performed with `psql -c`:
Unpatched: 0.000061 seconds
Patched: 0.000061 seconds
Here's a look at the perf:
Unpatched:
0.59% [.] AllocSetAlloc
0.51% [.] hash_search_with_hash_value
0.47% [.] base_yyparse
Patched:
0.63% [.] AllocSetAlloc
0.52% [.] hash_search_with_hash_value
0.44% [.] base_yyparse
(*) select 1, 2, 3 from foo where a = 1
Is there a more relevant benchmark I could use?
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com