A certain C++ source file in my
workspace takes a very long time to compile. Though, the file is huge with
11000 lines of code, CC hangs for more than 1.5-2 hrs at this point before
progressing with the build.
-D_IOSTREAM_H_ -m64 -DSunOS -DRW_BROKEN_STRINGBUF_STR
-DRW_CLASSIC_STRING_CLASSES -D_REENTRANT -DRW_NO_STL -DRW_CENTURY_REQD
-D_RWCONFIG_12s -DBUILD64BIT -DNDEBUG=1 -O4
-DTRUE=1 -DFALSE=0 -erroff=hidevf
-library=iostream -xcode=pic32 -c
<srcfile>.cpp -o Release64/<srcfile>.o
I ran truss unix command on this and found it to be hanging
for iropt command for a very long time (more than 1 hr), though it continues then on.
Please advise how do I debug this issue further.
The iropt program is the optimizing phase of the compiler. At the -O4 optimizing level, iropt does quite a bit of work, including additional function inlining. Even so, I would expect a program of 11K lines to compile in under a minute at -O4 on a reasonable machine.
I would first look at the computer where you are running the compiler. Is it busy doing other things? Does it have enough real memory for all the work it is doing? The compiler process might be thrashing, spending all its time swapping pages between virtual and real memory.
Looking next at the compilation process itself, the cost of optimizing is more than linear in the size a function, the number of local variables, and the size of basic blocks (a stretch of code with no conditionals or other jumps). A large function, say several hundred lines of code, can take a long time to process. You can usually reduce compilation time, and often make your program easier to understand and maintain, if you break up a large, complicated function into smaller logical pieces. (Of course, that is not always reasonable.)
You can reduce compilation time by reducing the optimization level. That is a practical strategy during initial program development, when rapid build time is more important than faster execution speed. When you are no longer actively developing and debugging, and therefore compiling less frequently, raise the optimization level for final testing and performance analysis.
Finally, we are always looking for ways to reduce the time and memory needed to compile programs. Newer versions of Studio might compile your program faster. You can get the current version of Studio here:
If you have a service contract for Studio, you can work with your service representative to ask for specific compiler improvements if the compilation is due to inefficiencies in the compiler.
Thanks Steve for the response.
We recently upgraded to Sun Studio 12.3 (5.12 CC) on Solaris 11. It’s since then that I am facing this longer compilation time issue – 1.5-2hrs.
Here’s the top output on the m/c where I am compiling code.
1.09, 1.09, 1.08; up 33+21:01:56 04:29:43
67 processes: 65 sleeping, 2 on cpu
CPU states: 98.3% idle, 1.6% user, 0.2% kernel, 0.0% iowait, 0.0% swap
Kernel: 321 ctxsw, 17 trap, 732 intr, 132 syscall
Memory: 64G phys mem, 49G free mem, 4096M total swap, 4096Mfree swap
PID USERNAME NLWP PRI NICE SIZE RES STATE TIME CPU COMMAND
16828 builder 1 0 0 415M 372M cpu/15 81:31 1.56% iropt
198 rmsbatch 1 59 0 64M 47M sleep 4:49 0.01% scheduler
16825 rmsbatch 1 59 0 4616K 3784K cpu/55 0:13 0.00% top
If you notice here, iropt have been running since 81mins. I don’t see any output for iropt in truss log during that period. It seems like its simply hung, doing nothing.
On Solaris 10(16G RAM) and 5.8 CC compiler, the same file takes ~16 mins to compile. And I also noticed that iropt finishes quite quick, its ‘cg’ that takes more time in this case.
I'll also try your suggestion of using a lower optimization level. However, '-O4' option seems to be a problem only for this file.
OK, your machine has plenty of capacity. You are probably running into bug 15812005, which has been fixed in a patch to Studio 12.3. If you have a service contract for Studio with Oracle, you can download patches from http://myoraclesupport.oracle.com
As a workaround, try adding this undocumented option to the compiler command line for the module where iropt is taking too long:
Added the option -W2,-Rprefetch_cm
/opt/SUNWspro/bin/CC -I/opt/SUNWspro/prod/include/CC4 -I/app/home/builder/HEAD_RRO_REL/rroprod/Batch -I/app/home/builder/SourcePro/Ed12_no_stl/12s -I/app/home/builder/SourcePro/Ed12_no_stl/12s/include -I/tools/cplex/12.4/cplex/include/ilcplex -I/tools/cplex/12.4/cplex/include -I/tools/cplex/12.4/concert/include -I/tools/oracle/220.127.116.11/product/precomp/public -I/tools/oracle/18.104.22.168/product/rdbms/demo -I/tools/oracle/22.214.171.124/product/rdbms/public -D_RWSTD_FSTREAM_INCLUDED -D_IOSTREAM_H_ -m64 -DSunOS -DRW_BROKEN_STRINGBUF_STR -DRW_CLASSIC_STRING_CLASSES -D_REENTRANT -DRW_NO_STL -DRW_CENTURY_REQD -D_RWCONFIG_12s -DBUILD64BIT -DNDEBUG=1 -DTRUE=1 -DFALSE=0 -O4 -W2,-Rprefetch_cm -erroff=hidevf -library=iostream -xcode=pic32 -c AIRSegOptAdm.cpp -o Release64/AIRSegOptAdm.o
It has still been running since more than 2 hours.
Not sure if the stack trace is helpful.
builder@md1sisun12 ~$ pstack 1918
1918: /opt/SUNWspro/prod/bin/iropt -Qy -O4 -xarch=sparc -m64 -xchip=generic
00330950 element_of (f1d44f8, 5f9198, a7a7f80, 1d00b30, f23a788, 1e0) + 30
000995a4 refine_wo_type_matrix (4, 1, 6e6000, 6f2800, 1e12, 6f2c00) + 1c
00409918 do_alias_analysis (1, 0, 678400, 678400, 684c00, 67f800) + 7ac
002e5754 ???????? (5d0000, 684c00, 67f1e0, 0, 67f000, 0)
002e4140 ???????? (720010, b18480, 0, 6f2400, 4, 1)
002ea6ec main (0, 688000, 720010, 6f2800, b18480, 680400) + 828
0004c2a0 _start (0, 0, 0, 0, 0, 0) + d8
Thanks Steve. We do have a service contract and probably will report the bug.
For now, I am exploring the option of setting a reduced optimization level for a single file. I have posted a query regarding the same.