VS.NET Compiler performance

[Martin]

Is there a reason for (and hopefully a work-around to) the
VC++.NET's compiler "flushing" each output file to disk before compiling
the next one? I've noticed this in both the 2002 and 2003 releases.

The application in question is a normal unmanaged C++ MFC
application migrated from VC++ 6. There are many files in the project
(250-300+) but the majority are fairly small...

Unlike VC++6, it appears that the new compiler will only
start compiling the next file once the current file's output is
completely written to disk. I know this because

(a) the hard-disk is going crazy and
(b) the CPU is idling around 20% on average.

With VC++ 6 the CPU sat at basically 100% and
the disk light flashed now-and-then as the OS flushed lazily in the
background.

And it also appears to get slower and slower the further
into the compile (the CPU usage drops). It now takes about 3 times as
long to do a full compile as it did before...

A RAM disk definitely helps a lot but the one I have is 32MB
max and not enough to fit all of the files generated (upward of
70-80MB). Currently I can only fit the .OBJ files there, leaving .PCH,
..SBR etc. files on the disk.

However I cannot see I should need to go to this extreme!!

Any help/suggestions welcome!

 

[Eric Christoffersen [VCPP MSFT]]

Other things to check:

Try disabling /YX (automatic pre-compiled headers).

Check your build dependancies to see if you have a project-to-project dependancy. Sometimes projects imported from vc6
will be given dependancies that will cause the other project to be rebuilt for each file.

Eric Christoffersen
Microsoft Visual C++

 

[Martin]

What OS are you using?
Windows 2000 Server SP3 with VS.NET 2003

How much memory do you have?

512MB, of which typically at least half is available...

Is /GL (whole program optimization) enabled?

No, this is a debug build but it's the same with a release build and
then yes, it's presumably on.

Could you please share your project's compiler and linker command-line
options?

compiler:

/Od /G7 /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /FD /EHsc /MTd
/Yu"stdafx.h"
/Fp".\Debug/css.pch" /Fo"q:\css\Debug/" /Fd".\Debug/" /FR".\Debug/"
/W3 /nologo /c
/ZI /Gz /TP

(NB: drive Q: is the ramdisk, but as I mentioned it's not large enough
to fit all of the files on)


linker:

/OUT:".\Debug/css.exe" /INCREMENTAL /NOLOGO /DELAYLOAD:"OleAcc.dll"
/DEBUG /PDB:".\Debug/css.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X86
ltkrn_n.lib ltfil_n.lib ltdis_n.lib ltimg_n.lib rpcrt4.lib mpr.lib
odbc32.lib DelayImp.lib
\Dev\Sites\src\t2bill\Debug\t2bill.lib DelayImp.lib

Other things to check:

Try disabling /YX (automatic pre-compiled headers).

PCH is created explicitly not automatically (see command-line above)

Check your build dependancies to see if you have a project-to-project
dependancy. Sometimes projects imported from vc6 will be given
dependancies that will cause the other project to be rebuilt for each
file.

Not quite sure what you mean; the dependancies look OK. But I think I
would have noticed this happening.......??

It's definitely looking as if it's doing a full flush-file-to-disk
after each output file is written.

 

[Tanveer Gani [MSFT]]

--------------------

From: Martin <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vc
Subject: Re: VS.NET Compiler performance
Date: Wed, 27 Aug 2003 12:45:56 +0200
Organization: The South African Internet Exchange
Lines: 54
Message-ID: <[email protected]>
References: <[email protected]>

NNTP-Posting-Host: 196.25.64.218
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: ctb-nnrp2.saix.net 1061981081 3452 196.25.64.218 (27 Aug 2003 10:44:41 GMT)
X-Complaints-To: (e-mail address removed)
NNTP-Posting-Date: 27 Aug 2003 10:44:41 GMT
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4)

Gecko/20030624 Netscape/7.1 (ax)

X-Accept-Language: en-us, en
In-Reply-To: <[email protected]>
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP0
8.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.icl.net!newsfeed.f
jserv.net!proxad.net!peer1.news.newnet.co.uk!peer1.news.newnet.co.uk!zen.net
.uk!btnet-peer1!btnet-peer0!btnet!ctb-nntp1.saix.net!not-for-mail
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:27620
X-Tomcat-NG: microsoft.public.dotnet.languages.vc

Windows 2000 Server SP3 with VS.NET 2003


512MB, of which typically at least half is available...


No, this is a debug build but it's the same with a release build and
then yes, it's presumably on.



compiler:

/Od /G7 /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /FD /EHsc /MTd
/Yu"stdafx.h"
/Fp".\Debug/css.pch" /Fo"q:\css\Debug/" /Fd".\Debug/" /FR".\Debug/"
/W3 /nologo /c
/ZI /Gz /TP

(NB: drive Q: is the ramdisk, but as I mentioned it's not large enough
to fit all of the files on)


linker:

/OUT:".\Debug/css.exe" /INCREMENTAL /NOLOGO /DELAYLOAD:"OleAcc.dll"
/DEBUG /PDB:".\Debug/css.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X86
ltkrn_n.lib ltfil_n.lib ltdis_n.lib ltimg_n.lib rpcrt4.lib mpr.lib
odbc32.lib DelayImp.lib
\Dev\Sites\src\t2bill\Debug\t2bill.lib DelayImp.lib



PCH is created explicitly not automatically (see command-line above)


Not quite sure what you mean; the dependancies look OK. But I think I
would have noticed this happening.......??

It's definitely looking as if it's doing a full flush-file-to-disk
after each output file is written.

Martin,

Try this: go to Control Panel. Open up System Properties and set memory
usage in the performance options to be for optimized for "System Cache"
rather than "Programs".

Also, run the disk defragmenter on your disk. If your disk is fragmented
badly, PCHs can be fragmented and ruin performance.