Linker throughput

re: Linker throughput

patrick — Mon, 09 Nov 2009 09:29:47 GMT

I agree with the cpp->obj->module comment.

If I was in the compiler/linker business, I would start using RAM.

The result is a service/daemon:

- In-memory dependency graph(FindFirstChange etc.)

- Traditional dependency check will not be necessary 99.99% of the time. It's done already.

- Compiler pipes output directly to daemon

- Daemon links in-memory

- Daemon keeps result (dll/exe) in-memory

- Daemon outputs dll/exe on-demand.

Patrick

re: Linker throughput

vcblog — Fri, 23 Oct 2009 16:26:16 GMT

@Boris Sunik

Thanks for your suggestion! We appreciate it so much!

For the IncredBuild case, multiple PDB files will be generated, this will cost linker more time to merge them into one PDB.

For your first suggestion, i think reading some of object segments in second step will utilize the power of multithreading, one thread is blocked by IO, another is blocked by CPU.

Chandler

re: Linker throughput

Andre Vachon — Thu, 22 Oct 2009 13:47:06 GMT

The VC++ team spends a lot of time investigating linker throughput issues. The multi-threading work was done after demonstrating, through significant performance analysis of multiple scenarios, that it did actually increase overall performance

Maybe your scenario exposes unique performance problem, but overall, I don't think we have obvious bad practices in the linker.

Maybe I am wrong, and maybe there are. All I can say is we will continue to analyze linker performance, spending time understanding IO access patterns to further optimize throughput.

We know linker throughput is one of the most important things to our customers, and we'll keep doing whatever we can to improve it.

re: Linker throughput

Boris Sunik — Thu, 22 Oct 2009 11:00:35 GMT

One more remark.

It seems that linker simultaneously writes debug info and reads input modules.

Forming the complete debug info in memory and writing it at the program end will surely reduce the linking time.

re: Linker throughput

Boris Sunik — Wed, 21 Oct 2009 15:13:40 GMT

I am working in the team developing huge C++ applications with circa 4000 source files and 2500 obj files. VS2008. Debug and Release configuration are built with debug info without /LTCG flag. Debug use incremental linking, Release don't use it.

My machine is double core 2.3Gz 4096Mb

Our concern are unsatisfactory linking times. Linking Debug configuration takes between 20 and 1200 sec.

Linking Release lays between 270 and 1800 sec. Besonders much time takes linking with IncredBuild also with high priority.

I have two suggestions on the issue.

First linker takes 25 minutes to link and after that its CPU link time is only 19 seconds and storage 350Mb. It would be nice if you will have a special option like /HUGEPROJECT and read all object segments into the storage also on the first step. All modern computers have a lot of memory but it is simply doesn't used by your linker.

Second, your linker obviously lacks satisfactory prelink check in the incremental modus to know whether it is possible to update the project in proper time. Every linker starting from 7.0 fails to link in acceptable time, if the changes in files are a little more than tiny. In result non-incremental linking takes 4 minutes, incremental 15. It is something other than a satisfactory performance.

With Regards,

Boris

re: Linker throughput

vcblog — Wed, 14 Oct 2009 17:36:10 GMT

@Alexandre Grigoriev

1. Before writing to the final .PDB file, linker should check the debug information to assure no wrong data will be written. Unfortunately, the algorithm of this part is time-consuming.

2 & 3. As for file I/O, the most time is cost by Page Fault handling (Reading a page from disk and writing a page into disk). Usually (with enough memory/CPU available), it has little difference whether user call WriteFile/ReadFile for N times, each process one record, or call WriteFile/ReadFile just once which process N records.

4. As for ICF, linker will compare two COMDATs byte-by-byte before folding one of them, before that, linker will check some flags or characteristics to avoid such comparing. So if there many functions within one module (.obj file) which having same size of code and similar implementation, linker will be slowed down.

Chandler

re: Linker throughput

Alexandre Grigoriev — Mon, 12 Oct 2009 18:13:57 GMT

Also, how ICF (indentical COMDAT folding) affects the link time? Default BUILD script enables it by default, even in checked builds (which I believe is bad for setting breakpoints during debugging).

re: Linker throughput

Alexandre Grigoriev — Mon, 12 Oct 2009 18:02:24 GMT

A few observations:

1. PDB vs no-PDB difference tells that the binary write is much faster than PDB write. Why? I suppose you just have to dump the tables already built in memory. Parallelising them would save a pittance. A reason for longer PDB write could be that the current linker creates the PDB file as compressed. If you issue writes in pieces smaller than the compression unit (64K or so?) it could cause multiple compress-decompress rounds. I hope the linker is not calling WriteFile per each PDB record; that would just kill the performance.

2 Typically, it makes sense to avoid writing two large files in parallel in small pieces. The most effective approach is to build the data in memory and write it in one shot. With the modern memory sizes, it's feasible. And NO, a file mapping doesn't beat that; forget it. Especially a mapped compressed file (PDB).

3. If you deal with a lot of small files, it makes sense to read them to memory, as many as possible. To avoid disk thrashing, open a bunch of them at once, and then read; don't do one by one.

re: Linker throughput

David Nelson — Sat, 26 Sep 2009 02:34:17 GMT

@CMWoods,

It is standard practice in most professional development shops to store PDBs for all released binaries, even if the PDBs themselves are not released, for help in debugging. Adding /debug to the default template was an effect, not a cause.

re: Linker throughput

CMWoods — Fri, 25 Sep 2009 17:34:49 GMT

"Most users normally specify /debug when linking, irrespective of whether the application is built under “debug” or “release” configuration."

Are you sure that's actually intensional or is it more likely that "most users" just didn't notice that MS added /debug to the default project templates a few versions ago?