On 2015年04月30日 18:53, ishikawa wrote: > On 2015年04月30日 10:51, dliang wrote: >> actullay, now in mozilla build system, gold-ld is the default linker if your >> OS has already exist gold-ld, follow is codes copy from mozilla/configure, >> (my code version is tb-beta 34-b1): >> >> 10029 if test "$GNU_CC" -a -n "$MOZ_FORCE_GOLD"; then >> 10030 if $CC -Wl,--version 2>&1 | grep -q "GNU ld"; then >> 10031 GOLD=$($CC -print-prog-name=ld.gold) >> 10032 case "$GOLD" in >> 10033 /*) >> 10034 ;; >> 10035 *) >> 10036 GOLD=$(which $GOLD) >> 10037 ;; >> 10038 esac >> 10039 if test -n "$GOLD"; then >> 10040 mkdir -p $_objdir/build/unix/gold >> 10041 rm -f $_objdir/build/unix/gold/ld >> 10042 ln -s "$GOLD" $_objdir/build/unix/gold/ld >> 10043 if $CC -B $_objdir/build/unix/gold -Wl,--version 2>&1 | >> grep -q "GNU gold"; then >> 10044 LDFLAGS="$LDFLAGS -B $_objdir/build/unix/gold" >> 10045 else >> 10046 rm -rf $_objdir/build/unix/gold >> 10047 fi >> 10048 fi >> 10049 fi >> 10050 fi >> >> On 2015年04月29日 07:07, Mike Hommey wrote: >>> On Tue, Apr 28, 2015 at 05:24:16PM -0500, Joshua Cranmer ? wrote: >>>> On 4/28/2015 4:28 PM, ISHIKAWA, Chiaki wrote: >>>>> On 2015/04/28 23:30, Toan Pham wrote: >>>>>> Linking is a process of resolving symbols from object files with >>>>>> external libraries, and it should not take that long. When you have a >>>>>> chance, try to compile the project under a ram filesystem like tmpfs. >>>>>> I use it most of the time, even when I have an SSD drive. The tmpfs >>>>>> will speed up compilation significantly. >>>>>> >>>>> >>>>> With full debug build of thunderbird (without -gsplit-dwarf), I think >>>>> libxul.so becomes close to 1GB in size. >>>>> So creating it puts much workload in terms of I/O, and >>>>> in terms of memory pressure, too, since ordinary linker's data structure >>>>> to handle the large number of symbols simply runs out of 32-bit memory >>>>> space during linking. >>>>> >>>>> Currently with -gsplit-dwarf,libxul. it is 357.2MB. It is rather large. >>>>> >>>>> I may want to try to set aside 2GB of RAM to tmpfs given this size of >>>>> libxul.so, but as of now, linking libxul runs in a reasonable time by >>>>> using GNU gold linker and -gsplit-dwarf option to GCC. >>>>> >>>>> Thank you for the suggestion, if something goes wrong with >>>>> linking/build I may try to create a large tmpfs using RAM. >>>>> >>>>> At the same time, I have to report that I monitor the memory usage during >>>>> build, and saw most of memory is used as cache/buffer during linking. >>>>> Hence I am not sure if tmpfs based on RAM will bring about much speedup in >>>>> my environment. My CPU is probably 1 ~ 1.5 generation behind the latest >>>>> one. That may explain the slow speed. >>>> >>>> Linking effectively requires building a list of used files, concatenating >>>> the used sections together, dropping redundant COMDATs, and then patching >>>> offsets into the binary, which requires scanning all of the .o files at >>>> least once--the key, then, is to make sure that the scanning process never >>>> touches disk. In other words, you need enough RAM that the .o files stay >>>> resident in the file system cache from when they were last touched in a >>>> compile-edit-rebuild cycle. Outside of ensuring you have at least 8GB of >>>> RAM >>>> [1], the only recommendation I can give for speeding up is using >>>> split-dwarf >>>> (removes the ginormous debug information from the linking equation) and >>>> using gold, at least on Linux. I don't think ramfs style builds speed up >>>> builds if the filesystem is already resident in cache. >>> >>> (note gold is the default for local builds) >>> > > Dear Liang, > > I am not entirely sure if configure in my environment picks up GNU gold > automatically. > Actually I create a ~/bin/ld shell script that invokes GNU gold linker > explicitly. > and put my ~/bin near the beginning of PATH environment variable before > /usr/bin so that > "ld" noticed by configure is always my ~/bin/ld and invokes GNU gold no > matter what the symlink from /usr/bin/ld is. > (And this trick is useful for OTHER programs that don't look for GNU gold > seriously in its configure script.) > > You might want to check that your GNU gold on your computer under whatever > filename is > *IS* invoked during the build of TB. > (I suppose major linux distribution installs GNU gold linker as ld.gold by > default. But you may want to check just in case. What distribution of linux > do you use assuming you use linux?) > > If you link time is still in 10-20 minutes range using GNU gold linker, > you might want to increase RAM. > How much RAM do you have in your computer? > I think 8GB is bare minimum for comfortable linking. > (I am assuming that you use 64-bit OS.) > > Also, what is your CPU? I am just curious. > With four cores allocated to a virtual machine, my build time is not that > bad after a modification of several files including the not-so-long link > time (don't forget -gsplit-dwarf to CC option.) and this is inside VirtualBox. > > If you have a few disk drives, try spreading the > source files in one disk, the object tree in other disk, etc. > on different I/O channels (i.e., not multiplexing them on one bus) > if possible although this is easier said than done when your disks are > almost full already. > Also, try using the fastest disk for object files. [you may need > experimenting here.] > > That is all I can think of speeding up link time significantly. > > CI >
Dear ishikawa, ありがとうございますお忙しいところをお返事のメール, Your answer is perfectly solved my problems. Thank you very much. Now my TB re-build time has reduce to almost one minute and the time used in link libxul.so is nearly 20~50 seconds, this is all because of the build options " -gsplit-dwarf " . My cpu info is follow: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz stepping : 9 microcode : 0x17 cpu MHz : 1600.000 cache size : 6144 KB and my memory info: MemTotal: 8067636 kB MemFree: 2164108 kB Buffers: 564716 kB Cached: 3872940 kB my linux distribution is Ubuntu 14.04.2 LTS These facts proved that "-gsplit-dwarf" is an very useful option. About the discussion of gold-ld, i believe in the link process of libxul, TB build system use gold-ld, but in compile process , TB build system just use ld, so I use command "ln -s /usr/bin/gold /usr/bin/ld" to replace ld. And about the use of tmpfs, i think this will not save time after pratice, because my cpu usage is almost 100% in the all build process, so i think the cpu frequency is the limit factor of build time but not disk I/O. _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
