Re: remaining sql/json patches

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <johncnaylorls(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remaining sql/json patches
Date: 2023-11-29 19:21:59
Message-ID: 6faa13d7-62a1-aefa-962a-6f5586b5684b@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-11-29 We 12:42, Andres Freund wrote:
> Hi,
>
> On 2023-11-29 07:37:53 -0500, Andrew Dunstan wrote:
>> On 2023-11-28 Tu 21:10, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2023-11-28 20:58:41 -0500, Andrew Dunstan wrote:
>>>> On 2023-11-28 Tu 19:32, Tom Lane wrote:
>>>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>>> So I'm now a bit baffled. Can you provide more color on what
>>>>> your test setup is?
>>>> *sigh* yes, you're right. I inadvertently used a setup that used meson for
>>>> building REL16_STABLE and HEAD. When I switch it to autoconf I get results
>>>> that are similar to the earlier branches:
>>>>
>>>>
>>>> ==== REL_16_STABLE ====
>>>> Time: 3401.625 ms (00:03.402)
>>>> ==== HEAD ====
>>>> Time: 3419.088 ms (00:03.419)
>>>>
>>>>
>>>> It's not clear to me why that should be. I didn't have assertions enabled
>>>> anywhere. It's the same version of bison, same compiler throughout. Maybe
>>>> meson sets a higher level of optimization? It shouldn't really matter, ISTM.
>>> Is it possible that you have CFLAGS set in your environment? For reasons that
>>> I find very debatable, configure.ac only adds -O2 when CFLAGS is not set:
>>>
>>> # C[XX]FLAGS are selected so:
>>> # If the user specifies something in the environment, that is used.
>>> # else: If the template file set something, that is used.
>>> # else: If coverage was enabled, don't set anything.
>>> # else: If the compiler is GCC, then we use -O2.
>>> # else: If the compiler is something else, then we use -O, unless debugging.
>>>
>>> if test "$ac_env_CFLAGS_set" = set; then
>>> CFLAGS=$ac_env_CFLAGS_value
>>> elif test "${CFLAGS+set}" = set; then
>>> : # (keep what template set)
>>> elif test "$enable_coverage" = yes; then
>>> : # no optimization by default
>>> elif test "$GCC" = yes; then
>>> CFLAGS="-O2"
>>> else
>>> # if the user selected debug mode, don't use -O
>>> if test "$enable_debug" != yes; then
>>> CFLAGS="-O"
>>> fi
>>> fi
>>>
>>> So if you have CFLAGS set in the environment, we'll not add -O2 to the
>>> compilation flags.
>>>
>>> I'd check what the actual flags are when building a some .o.
>>>
>> I do have a CFLAGS setting, but for meson I used '-Ddebug=true' and no
>> buildtype  or optimization setting. However, I see that in meson.build we're
>> defaulting to "buildtype=debugoptimized" as opposed to the standard meson
>> "buildtype=debug", so I guess that accounts for it.
>>
>> Still getting used to this stuff.
> What I meant was whether you set CFLAGS for the *autoconf* build,

That's what I meant too.

> because that
> will result in an unoptimized build unless you explicitly add -O2 (or whatnot)
> to the flags. Doing benchmarking without compiler optimizations is pretty
> pointless.
>

Right. My latest reported results should all be at -O2.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-29 19:39:20 Re: Fix some memory leaks in ecpg.addons
Previous Message Andres Freund 2023-11-29 19:20:14 Re: Fix some memory leaks in ecpg.addons