Re: Splitting up guc.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Splitting up guc.c
Date: 2022-09-10 19:35:05
Message-ID: 599818.1662838505@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
>>> $ size guc*o
>>> text data bss dec hex filename
>>> 13653 4 112 13769 35c9 guc-file.o
>>> 54953 0 564 55517 d8dd guc.o
>>> 6951 0 112 7063 1b97 guc_hooks.o
>>> 43570 62998 216 106784 1a120 guc_tables.o

>> A tad surprised by the text size of guc_tables.o - not that it is a problem,
>> just seems a bit odd.

> There's a pretty fair number of constant tables that got moved to there.
> Not to mention all the constant strings.

I forgot to include comparison numbers for HEAD:

$ wc guc*c
2629 9372 69467 guc-file.c
13335 41584 356896 guc.c
15964 50956 426363 total
$ size guc*o
text data bss dec hex filename
13653 4 112 13769 35c9 guc-file.o
105848 63156 908 169912 297b8 guc.o

This isn't completely apples-to-apples because of the few
hook functions I'd moved to other places in v1, but you can
see that the total text and data sizes didn't change much.
It'd likely indicate a mistake if they had. (However, v1
does include const-ifying a few options tables that had
somehow escaped being labeled that way, so the total data
size did shrink a small amount.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-09-10 20:05:42 Re: CI and test improvements
Previous Message Andres Freund 2022-09-10 19:24:40 Re: Splitting up guc.c