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? -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
