On Nov 16, 2023, at 17:48, Amit Langote <amitlangot...@gmail.com> wrote: > On Thu, Nov 16, 2023 at 2:11 AM Andres Freund <and...@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?
Thought I’d share a few more numbers I collected to analyze the parser size increase over releases. * gram.o text bytes is from the output of `size gram.o`. * compiled with -O3 version gram.o text bytes %change gram.c bytes %change 9.6 534010 - 2108984 - 10 582554 9.09 2258313 7.08 11 584596 0.35 2313475 2.44 12 590957 1.08 2341564 1.21 13 590381 -0.09 2357327 0.67 14 600707 1.74 2428841 3.03 15 633180 5.40 2495364 2.73 16 653464 3.20 2575269 3.20 17-sqljson 672800 2.95 2709422 3.97 So if we put SQL/JSON (including JSON_TABLE()) into 17, we end up with a gram.o 2.95% larger than v16, which granted is a somewhat larger bump, though also smaller than with some of recent releases. > -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
