Re: small development tip: Consider using the gold linker

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: small development tip: Consider using the gold linker
Date: 2022-01-14 03:24:09
Message-ID: CAH2-Wz=5MX0v9kEzSom9T7JNNW4AzPFFkCuY=e19KDP-=+z9Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 20, 2018 at 8:16 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, Jul 9, 2018 at 4:40 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > FWIW, I've lately noticed that I spend a fair time waiting for the
> > linker during edit-compile-test cycles. Due to an independent issue I
> > just used the gold linker, and the speedup is quite noticable.
> > For me just adding '-fuse-ld=gold' to CFLAGS works.
>
> I tried this out today. It makes quite a noticeable difference for me.
> Thanks for the tip.

The 2022 version of the same tip: switching over to LLVM lld seems to
offer a further significant speedup over gold. Not surprising, since
lld is specifically promoted as a linker that is faster than gold [1].
Again, this appears to just be a case of installing lld, and adding
'-fuse-ld=lld' to CFLAGS -- a very easy switch to make. Link time is
still a noticeable contributor to overall build time for me, even with
gold (I use ccache, of course).

There is another linker called mold [2]. It claims to be faster than
lld (which was faster than gold, which was faster than ld). I didn't
bother trying it out.

[1] https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf - slide 14
[2] https://github.com/rui314/mold
--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-01-14 03:25:34 Consistently use the function name CreateCheckPoint instead of CreateCheckpoint in code comments
Previous Message Michael Paquier 2022-01-14 03:23:27 Re: Refactoring of compression options in pg_basebackup