From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speed up clean meson builds by ~25% |
Date: | 2024-04-09 23:11:37 |
Message-ID: | 20240409231137.l3fb4oti5ym3265k@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-04-09 15:33:10 -0700, Andres Freund wrote:
> Which leads to a control flow graph with *many* incoming edges to the basic
> block containing the function call to mm_strdup(), triggering a normally
> harmless O(N^2) or such.
With clang-16 -O2 there is a basic block with 3904 incoming basic blocks. With
the hacked up preproc.y it's 2968. A 30% increase leading to a doubling of
runtime imo seems consistent with my theory of there being some ~quadratic
behaviour.
I suspect that this is also what's causing gram.c compilation to be fairly
slow, with both clang and gcc. There aren't as many pstrdup()s in gram.y as
the are mm_strdup() in preproc.y, but there still are many.
ISTM that there are many pstrdup()s that really make very little sense. I
think it's largely because there are many rules declared %type <str>, which
prevents us from returning a string constant without a warning.
There may be (?) some rules that modify strings returned by subsidiary rules,
but if so, it can't be many.
Greetings,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-04-09 23:22:38 | Re: Speed up clean meson builds by ~25% |
Previous Message | Alexander Korotkov | 2024-04-09 23:03:40 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |