too slow to build clang

hi,everyone.
I logined llvm’s bugzilla,got a bug.And I want to fix it.
I add only debug statement to output something ,and than build clang in my FreeBSD 7.1 in vmware.
I found it took about tens of minutes.Although my machine is a little slow (celeron 2.4 G cpu),
I think it took too many minutes.Maybe there something is wrong.


|

hi,everyone.
I logined llvm’s bugzilla,got a bug.And I want to fix it.

Great!


I add only debug statement to output something ,and than build clang in my FreeBSD 7.1 in vmware.
I found it took about tens of minutes.Although my machine is a little slow (celeron 2.4 G cpu),
I think it took too many minutes.Maybe there something is wrong.

Clang and LLVM are relatively large, so it does take some time to compile them. The biggest issue is often memory: does your VMware virtual machine have at least 1 GB memory?

Also, it helps to configure LLVM with --enable-targets=. Otherwise, you’re spending a lot of time compiling and linking back-end targets you probably don’t care about (Sparc, Cell, etc.).

  • Doug

It seemed to me like he was saying that after the initial build, changing a single file (presumably not a header file) still required a substantial rebuild. But I'm just speculating. Using the Xcode build project, I have not experienced this to be the case.

The rebuild is pretty minimal for the makefiles, too, although linking takes a while.

  - Doug

I wonder if we could link with gold ?

Only on linux at this point.

-eric

Aww. Boo linux...always messing things up.

In more seriousness, what would it take to run gold on Mac OS X?

Someone to port it to handle Mach-O. I'm not sure what this would take. ld64 isn't too bad on OSX though for link times.

-eric

Major and invasive changes to the OS X loader. Gold is fast because it only supports one binary format, ELF, while the older GNU ld supports a.out, ELF and COFF. OS X uses Mach-O, and is not supported by either.

I don't know how Gold compares in terms of performance to the NeXT / Apple linker, but I'd be surprised if there was a big difference in performance since the Apple linker hasn't inherited the same level of cruft as the GNU linker from having multiple binary formats added over time.

Porting Gold to *BSD should be relatively easy, but no one appears to have both the skill and the motivation to do so.

David

If Google hadn't signed to copyright over to the FSF and/or had released
to code under a BSDL or similar license, there would probably be quite
a bit of interest. At things stand, the BSD projects are trying to
delay or avoid entirely the day when they have to use a GPLv3 licensed
binutils. Yet another elf linker is probably more likely. :frowning:

-- Brooks

Ah. I was sort-of assuming part of the bottleneck (on OS X) was gnu ld. I didn't really realize that Mac OS X had its own linker. At my day job, I suffer through horrible long gnu ld stages, so it's on my mind.

That's interesting to note. What a pity.

The apple linker was completely rewritten for the 10.5 tools release, if you find a case where it is slow, please email me off-list.

-Chris

Douglas Gregor wrote:

Clang and LLVM are relatively large, so it does take some time to
compile them. The biggest issue is often memory: does your VMware
virtual machine have at least 1 GB memory?

And more! My computer has 1GB of memory, and the linker always started
swapping like crazy - took about 5-6 minutes to link Clang. I upgraded
to 3GB, and now it takes 30 seconds.

Sebastian

Note that certain versions of binutils (e.g. 2.17) are particularly bad. See http://llvm.org/docs/GettingStarted.html#brokengcc for a list. It might be worthwhile to try upgrading if you're using binutils and it is really slow.

-Chirs