Reducing link time on large C++ executable.

[Jeroen Dirks]

The project I am working currently results in a large executable.

The size of the executable when linked is about 150MB (including -g debug info).

We mostly work on Linux but sometimes we also work with the 64 but HP-UX platform. What we find is that linking takes way longer (> half hour) on HP than in our Linux environment (2 minutes).

When doing a top it seems that pxdb64 is running at 100% CPU.

Does anyone have tips of what can be done to reduce this link time? This is a dev build so if we can turn off some optimization in order to better link times we would be willing to do that.

/usr/ccs/bin/ld -o EXE64 libmod1.a /opt/langtools/lib/pa20_64/crt0.o -u ___exit -u main -L/apps/1151/aps64_src/orahome/8063/lib64 libmsc.a /apps/1151/aps64_src/sht/11.5.0/lib/ilog_64bit/libschedule.a /apps/1151/aps64_src/sht/11.5.0/lib/ilog_64bit/libsolver.a /apps/1151/aps64_src/sht/11.5.0/lib/ilog_64bit/libconcert.a /apps/1151/aps64_src/sht/11.5.0/lib/ilog_64bit/libcplex.a /apps/1151/aps64_src/sht/11.5.0/lib/ilog_64bit/libhybrid.a /apps/1151/aps64_src/sht/11.5.0/lib/rwave_64bit/libstd8s.a /apps/1151/aps64_src/fnd/11.5.0/lib/libfnd.a -lsql /apps/1151/aps64_src/orahome/8063/lib64/nautab.o /apps/1151/aps64_src/orahome/8063/lib64/naeet.o /apps/1151/aps64_src/orahome/8063/lib64/naect.o /apps/1151/aps64_src/orahome/8063/lib64/naedhs.o -lnetwork -lsns -lnetwork -lsns -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lclient -lvsn -lcommon -lgeneric -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -l:libcl.a -l:librt.sl -lpthread -l:libnss_dns.1 -l:libdld.sl -lm /apps/1151/aps64_src/orahome/8063/rdbms/lib64/defopt.o /apps/1151/aps64_src/orahome/8063/rdbms/lib64/ssdbaed.o /usr/lib/pa20_64/libstd.a -lstream -lCsup -lm -lcl -lc /usr/lib/pa20_64/libdld.sl

[James R. Ferguson]

Hi:

You haven't provided any details of system load/performance/capability other than to say it's fast on one server and slow on another.

Regards!

...JRF...

[Jeroen Dirks]

I do not actually know all the stats on that server. I am developer and not IT on that box.

What I do know is that it is a 6 CPU server and I am the only one using it while doing that link (from using top).

I know that there is not a factor 100 difference in CPU performance between our Intel 32-bit Linux box and our 64-bit HP-UX server. So I was hoping that some flags could be changed to reduce the link time.

[Steven E. Protter]

Shalom,

I don't think link flags are going to have a huge impact on link time.

Those flags are generally chosen for how you want the binary to be built and messing around with them may impact the final product.

Linking is CPU intensive, might in this case do substantial disk writes.

The only suggest for speeding it up, is running it on a more powerful or less busy machine.

SEP

[Dennis Handly · Accepted solution]

>When doing a top it seems that pxdb64 is running at 100% CPU.

No need to say any more. There is an option just for that. Read the documentation carefully for the disadvantages.
http://docs.hp.com/en/14672/Help/options.htm#opt+noobjdebug

>So I was hoping that some flags could be changed to reduce the link time.

This has nothing to do with "link" time. It is related to what happens after linking, the redundant debug info elimination in pxdb.

This is one of those "pay me now or pay me later" issues. If you link once and never debug, you can use:
export LD_PXDB=/usr/bin/true
You will pay that cost the first time you use gdb on it.

Or you can compile with +objdebug, this leaves the debug info in the objects and only lookup tables in the executable. This does make gdb slower when debugging where it has to incrementally find the proper object files. If you are distributing your executable, you would also have to ship the objects, or not use this option.

On IPF we have made +objdebug the default.

>JRF: You haven't provided any details of system load/performance/capability other than to say it's fast on one server and slow on another.

The technical term here is "sucks". :-)
And it has nothing to do with servers but with the debug info architecture.

>SEP: I don't think link flags are going to have a huge impact on link time.

There are a couple of options that will help, basically by saying "don't do that now".

[Jeroen Dirks]

Some progress has been made...
The original 'link' took 52 minutes.

Now I have set LD_PXDB=/dev/null on the build machine.

There link time is now 4 minutes.

Starting gdb on the test machines takes about 3.5 minutes the first time for the pxdb step. It did 41367 procedures.

So overall this is a good improvement since we will not always need to run under gdb and even if we do the total time is smaller than the original.

I think that we be using older versions of the development tools. When starting gdb64 it reports in as HP gdb 5.2 for PA-RISC 2.0 (wide), HP-UX 11.0 and target hppa2.0w-hp-hpux11.00.

Have there been any significant performance improvements done in gdb/pxdb? And would they be backwards compatible with executable created by older versions of the compiler/linker?

[Dennis Handly]

>Starting gdb on the test machines takes about 3.5 minutes the first time for the pxdb step.
>... even if we do the total time is smaller than the original.

Hmm, I would have thought it would take 1/2 hour too.
Do you have the executable sizes before and after that gdb step?

>When starting gdb64 it reports in as HP gdb 5.2 for PA-RISC 2.0 (wide)

The latest is 6.0.

>Have there been any significant performance improvements done in gdb/pxdb?

Several years ago they sped up pxdb. But I don't know what your aC++ version is.

>And would they be backwards compatible with executable created by older versions of the compiler/linker?

They are forward compatible, yes. While you can download the latest gdb, you can't get pxdb.

[Dennis Handly]

If our answers were helpful, please read the following about assigning points:
http://forums.itrc.hp.com/service/forums/helptips.do?#33