On 19.05.24 00:09, Andres Freund wrote:
On 2024-05-18 00:35:08 +0200, Peter Eisentraut wrote:
I retested the patch from 2024-04-07 (I think that's the one that "fixed
that"? There are multiple "v1" patches in this thread.) using gcc-14 and
clang-18, with ccache disabled of course. The
On Mon, May 20, 2024 at 11:37 AM Andres Freund wrote:
> On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> > On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > > A few tests with ccache disabled:
> >
> > These tests seem to show no difference between the two releases, so I
> > wonder what
On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > A few tests with ccache disabled:
>
> These tests seem to show no difference between the two releases, so I
> wonder what you're intending to demonstrate here.
They show a few seconds of
On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> A few tests with ccache disabled:
These tests seem to show no difference between the two releases, so I
wonder what you're intending to demonstrate here.
Locally, I have ninja 1.11.1. I'm sure Andres will be absolutely
shocked, shocked I
Alvaro Herrera writes:
> On 2024-May-17, Robert Haas wrote:
>> Anyone else want to vote?
> I had pretty much the same thought as you. It seems a waste to leave
> the code in existing branches be slow only because we have a much better
> approach for a branch that doesn't even exist yet.
I
On 2024-May-17, Robert Haas wrote:
> Anyone else want to vote?
I had pretty much the same thought as you. It seems a waste to leave
the code in existing branches be slow only because we have a much better
approach for a branch that doesn't even exist yet.
--
Álvaro Herrera PostgreSQL
On 17.05.24 23:01, Robert Haas wrote:
On Fri, May 17, 2024 at 4:59 PM Tom Lane wrote:
As I mentioned upthread, I'm more worried about confusing error
reports than the machine time.
Well, Jelte fixed that.
I grant that there are people who are more affected, but still, I'd
just as soon not
On Fri, May 17, 2024 at 4:59 PM Tom Lane wrote:
> As I mentioned upthread, I'm more worried about confusing error
> reports than the machine time.
Well, Jelte fixed that.
> I grant that there are people who are more affected, but still, I'd
> just as soon not contort the build rules for a
Robert Haas writes:
> If this is the consensus opinion, then
> https://commitfest.postgresql.org/48/4914/ should be marked Rejected.
> However, while I think the improvements that Tom was able to make here
> sound fantastic, I don't understand why that's an argument against
> Jelte's patches.
On Wed, Apr 17, 2024 at 11:11 PM Tom Lane wrote:
> I think we should hold off on this. I found a simpler way to address
> ecpg's problem than what I sketched upthread. I have a not-ready-to-
> show-yet patch that allows the vast majority of ecpg's grammar
> productions to use the default
Andres Freund writes:
> On 2024-04-17 23:10:53 -0400, Tom Lane wrote:
>> I think we should hold off on this. I found a simpler way to address
>> ecpg's problem than what I sketched upthread. I have a not-ready-to-
>> show-yet patch that allows the vast majority of ecpg's grammar
>> productions
On 2024-04-17 23:10:53 -0400, Tom Lane wrote:
> Jelte Fennema-Nio writes:
> > As I expected this problem was indeed fairly easy to address by still
> > building "backend/parser" before "interfaces". See attached patch.
>
> I think we should hold off on this. I found a simpler way to address
>
Jelte Fennema-Nio writes:
> As I expected this problem was indeed fairly easy to address by still
> building "backend/parser" before "interfaces". See attached patch.
I think we should hold off on this. I found a simpler way to address
ecpg's problem than what I sketched upthread. I have a
On Wed, 17 Apr 2024 at 16:00, Tom Lane wrote:
> Break gram.y (say, misspell some token in a production) and
> see what happens. The behavior's likely to be timing sensitive
> though.
Thanks for clarifying. It took me a little while to break gram.y in
such a way that I was able to consistently
Jelte Fennema-Nio writes:
> How can I test if this actually happens? Because it sounds like if
> that indeed happens it should be fixable fairly easily.
Break gram.y (say, misspell some token in a production) and
see what happens. The behavior's likely to be timing sensitive
though.
On Wed, 17 Apr 2024 at 13:41, Peter Eisentraut wrote:
>
> On 10.04.24 17:33, Tom Lane wrote:
> > The immediate question then is do we want to take Jelte's patch
> > as a way to ameliorate the pain meanwhile. I'm kind of down on
> > it, because AFAICS what would happen if you break the core
> >
On 10.04.24 17:33, Tom Lane wrote:
The immediate question then is do we want to take Jelte's patch
as a way to ameliorate the pain meanwhile. I'm kind of down on
it, because AFAICS what would happen if you break the core
grammar is that (most likely) the failure would be reported
against ecpg
Thomas Munro writes:
> On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote:
>> I don't doubt that there are other clang versions where the problem
>> bites a lot harder. What result do you get from the test I tried
>> (turning mm_strdup into a no-op macro)?
> #define mm_strdup(x) (x) does this:
>
On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote:
> I don't doubt that there are other clang versions where the problem
> bites a lot harder. What result do you get from the test I tried
> (turning mm_strdup into a no-op macro)?
#define mm_strdup(x) (x) does this:
Apple clang 15: master: 14s ->
Thomas Munro writes:
> On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
>> ... On my Mac laptop
>> (Apple clang version 15.0.0), the compile time for preproc.o went from
>> 6.7sec to 5.5sec.
> Having seen multi-minute compile times on FreeBSD (where clang is the
> system compiler) and Debian
On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
> ... On my Mac laptop
> (Apple clang version 15.0.0), the compile time for preproc.o went from
> 6.7sec to 5.5sec.
Having seen multi-minute compile times on FreeBSD (where clang is the
system compiler) and Debian (where I get packages from
Andres Freund writes:
> On 2024-04-09 20:12:48 -0400, Tom Lane wrote:
>> In any case, this is all moot unless we can come to a new design for
>> how ecpg does its string-mashing. Thoughts?
> Am I missing something, or is ecpg string handling almost comically
> inefficient? Building up strings
Hi,
On 2024-04-09 20:12:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, just redefining mm_strdup() that way doesn't help much here either,
> > even with an affected compiler. The gain increases substantially after
> > simplifying unreserved_keyword etc to just use the default
Andres Freund writes:
> On 2024-04-09 19:44:03 -0400, Tom Lane wrote:
>> As you did, I wasn't trying to get to a working result, so I didn't do
>> anything about removing all the free's or fixing the cast-away-const
>> warnings. The result was disappointing though. On my Mac laptop
>> (Apple
Hi,
On 2024-04-09 19:44:03 -0400, Tom Lane wrote:
> I experimented with replacing mm_strdup() with
>
> #define mm_strdup(x) (x)
>
> As you did, I wasn't trying to get to a working result, so I didn't do
> anything about removing all the free's or fixing the cast-away-const
> warnings. The result
Andres Freund writes:
> On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Why are strduping all of these?
>> IIRC, the issue is that the mechanism for concatenating the tokens
>> back together frees the input strings
> Ah, that explains it - but also seems somewhat
Hi,
On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we need to do something about the compile time of this file, even
> > with
> > gcc. Our main grammar already is an issue and stacking all the ecpg stuff on
> > top makes it considerably worse.
>
> Seems
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
Andres Freund writes:
> I think we need to do something about the compile time of this file, even with
> gcc. Our main grammar already is an issue and stacking all the ecpg stuff on
> top makes it considerably worse.
Seems reasonable, if we can.
> Why are strduping all of these?
IIRC, the
Hi,
On 2024-04-09 17:13:52 +1200, Thomas Munro wrote:
> On Tue, Apr 9, 2024 at 5:01 PM Michael Paquier wrote:
> > On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> > > On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
> > >> As I wrote in [1], I didn't observe the issue
On Tue, Apr 9, 2024 at 5:01 PM Michael Paquier wrote:
> On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> > On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
> >> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
> >> is fixed already.
> >> Perhaps
On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
>> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
>> is fixed already.
>> Perhaps it's worth rechecking...
>>
>> [1]
>>
Hi,
On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
>
> Hello Michael,
>
> 08.04.2024 08:23, Michael Paquier wrote:
> > On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
> >> Agreed. While not a full solution, I think this patch is still good to
> >> address some of the
Hello Jelte,
08.04.2024 11:36, Jelte Fennema-Nio wrote:
On Mon, 8 Apr 2024 at 10:00, Alexander Lakhin wrote:
As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
is fixed already.
Perhaps it's worth rechecking...
Using the attached script I got these timings. Clang is
On Mon, 8 Apr 2024 at 10:02, Peter Eisentraut wrote:
> I have tested this with various compilers, and I can confirm that this
> shaves off about 5 seconds from the build wall-clock time, which
> represents about 10%-20% of the total time. I think this is a good patch.
Great to hear.
>
On Mon, 8 Apr 2024 at 10:00, Alexander Lakhin wrote:
> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
> is fixed already.
> Perhaps it's worth rechecking...
Using the attached script I got these timings. Clang is significantly
slower in all of them. But especially with
On 05.04.24 18:19, Jelte Fennema-Nio wrote:
On Fri, 5 Apr 2024 at 17:24, Andres Freund wrote:
I recommend opening a bug report for clang, best with an already preprocessed
input file.
We're going to need to do something about this from our side as well, I
suspect. The times aren't great
Hello Michael,
08.04.2024 08:23, Michael Paquier wrote:
On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
Agreed. While not a full solution, I think this patch is still good to
address some of the pain: Waiting 10 seconds at the end of my build
with only 1 of my 10 cores doing
On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
> Agreed. While not a full solution, I think this patch is still good to
> address some of the pain: Waiting 10 seconds at the end of my build
> with only 1 of my 10 cores doing anything.
>
> So while this doesn't decrease CPU
On Fri, 5 Apr 2024 at 17:24, Andres Freund wrote:
> I recommend opening a bug report for clang, best with an already preprocessed
> input file.
> We're going to need to do something about this from our side as well, I
> suspect. The times aren't great with gcc either, even if not as bad as with
Hi,
On 2024-04-05 15:36:34 +0200, Jelte Fennema-Nio wrote:
> On Fri, 5 Apr 2024 at 00:45, Jelte Fennema-Nio wrote:
> > It improved clean build times on my machine (10 cores/20 threads) from ~40
> > seconds to ~30 seconds.
>
> After discussing this off-list with Bilal, I realized that this gain
On Fri, 5 Apr 2024 at 00:45, Jelte Fennema-Nio wrote:
> It improved clean build times on my machine (10 cores/20 threads) from ~40
> seconds to ~30 seconds.
After discussing this off-list with Bilal, I realized that this gain
is only happening for clang builds on my system. Because those take a
Building the generated ecpg preproc file can take a long time. You can
check how long using:
ninja -C build src/interfaces/ecpg/preproc/ecpg.p/meson-generated_.._preproc.c.o
This moves that file much closer to the top of our build order, so
building it can be pipelined much better with other
43 matches
Mail list logo
