long library build times

[dajum]

Building my .lib files has started taking a very long time and I don't understand why.  It can take about 8 minutes now to create the 64 bit libraries.  The actual libraries are about 19MB in size.  About 1500 subroutines.  It seems they used to build about about 1-2 minutes and there may be a few more routines, but nothing large.  When I watch it in the task manager I see xilink.exe is doing over 40 GB or I/O reads.  That would appear to be the problem,  but I don't know what I could be doing to cause this.  Any help getting this reduced would be appreciated. 

From VS2008 property pages:

The librarian commands look like: /OUT:"..\x64\procesOpenMP.lib" /NOLOGO ..\x64\proces_lib.lib ..\amg\x64\Release\amgcg.lib

The compile step looks like: /nologo /O3 /Qunroll:35 /I"..\include" /I"..\include\fluint" /extend_source:132 /Qopenmp /Qopenmp-report2 /integer_size:64 /real_size:64 /assume:byterecl /fpe:0 /iface:cref /iface:mixed_str_len_arg /module:"x64\ReleaseOpenMP" /object:"x64\ReleaseOpenMP/" /traceback /libs:static /threads /c

Thanks,

Dave

[jimdempseyatthecove]

If you want faster compile time and/or smaller generated code, consider disabling IPO (Inter-Procedural Optimizations). Note, IPO can be set for all files in library or file-by-file, or disabled. Experiment to get the desired results. Jim Dempsey

[dajum]

By default IPO isn't on (Says no in porperty pages). It isn't listed in my options list. The time I reference is for xilink. I don't think the IPO plays into this picture. Does it?

[jimdempseyatthecove]

Is a network share involved? (where the tools are located, where the input files are located, where the output files are located) There was an issue posted earlier relating to network shares. (lone time ago). If so, search the forum messages (with Google) including: network slowdown. If not, does watching the output window show where the slow down is in the process? A potential cause is the module files being unnecessarily re-compiled (several times) during build due to circular references. Jim Dempsey

[dajum]

This is on a laptop without anything being shared across a network. The problem is in XILINK. It takes 8 minutes to run. But the real clue is that it does 40 GB of I/O reads. That is like reading every .obj file in my library 2000 times. There are no compiles happening. It is just reading something over and over it appears. Why that happens is not apparent to me from the input I listed. It seems like it might be reading the entire library for each .obj in library. Even though I'm only recompiling one or two routines out of the thousands. Maybe another clue is that this is using VS2008 and IVF11.1.065. I also have VS2010 and IVF XE2011 installed, but that is for other projects. This needs someone who knows what's in XILINK to help figure this out. Dave

[Steven_L_Intel1]

XILINK is the Intel "pre-linker". It scans the object input to see if there is any IPO work that needs to be done and then calls the Microsoft linker. I vaguely recall seeing an earlier report of s similar problem - are you willing to provide a ZIP of your project to us so we can see if it can be reproduced here? You can do this through Intel Premier Support if you wish.

[jimdempseyatthecove]

What I think is happening is along the line of: build A.lib build B.lib (with calls to A, invoking IPO with A) build C.lib (with calls to A and B invoking IPO with A and B) ... Open the solution Linker Property page, under optimization Disable Interprocedural Optimization. Note, this is the Linker Property page, not the Fortran Optimization page (in there you would set Interprocedural Optimization to Single File) Jim Dempsey

[Bernard]

>>>When I watch it in the task manager I see xilink.exe is doing over 40 GB or I/O reads.>>> Can you monitor the building process with Process Explorer?If you can locate the bottleneck and thread(s) which created it you can narrow down the problem to single function(s), by observing the call stack. If the I/O activity is related to your HDD my advise is to monitor disk accesses with filemon.exe and diskmon tools.