From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plenty code is confused about function level static |
Date: | 2024-04-18 07:00:59 |
Message-ID: | fa65be0e-b3f5-4977-bfbc-30f07137c307@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18/04/2024 00:39, Andres Freund wrote:
> Hi,
>
> We have a fair amount of code that uses non-constant function level static
> variables for read-only data. Which makes little sense - it prevents the
> compiler from understanding
>
> a) that the data is read only and can thus be put into a segment that's shared
> between all invocations of the program
> b) the data will be the same on every invocation, and thus from optimizing
> based on that.
>
> The most common example of this is that all our binaries use
> static struct option long_options[] = { ... };
> which prevents long_options from being put into read-only memory.
>
>
> Is there some reason we went for this pattern in a fair number of places? I
> assume it's mostly copy-pasta, but...
>
>
> In practice it often is useful to use 'static const' instead of just
> 'const'. At least gcc otherwise soemtimes fills the data on the stack, instead
> of having a read-only data member that's already initialized. I'm not sure
> why, tbh.
Weird. I guess it can be faster if you assume the data in the read-only
section might not be in cache, but the few instructions needed to fill
the data locally in stack are.
> Attached are fixes for struct option and a few more occurrences I've found
> with a bit of grepping.
+1
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-04-18 07:02:18 | Re: Support a wildcard in backtrace_functions |
Previous Message | Ajin Cherian | 2024-04-18 06:26:22 | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |