By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,967 Members | 1,324 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,967 IT Pros & Developers. It's quick & easy.

VS.NET Compiler performance - follow-up

P: n/a
The original question is at the bottom:

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

/Od /G7 /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /FD /EHsc /MTd
/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)

/OUT:".\Debug/css.exe" /INCREMENTAL /NOLOGO /DELAYLOAD:"OleAcc.dll"
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.

Martin wrote:
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

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!

Jul 19 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.