[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3425.0. "V5.4 compiler performance?" by CSC32::J_HENSON (Don't get even, get ahead!) Mon Feb 03 1997 12:30

C++ V5.4, OpenVMS V7.1, not sure of architecture

A customer is reporting that compile time and resource usage for C++
is very slow and expensive.  He is trying to compile a ~15k line
program, and it just about stops everything else on the cpu.

He will get some tuning assistance for this to make sure that it's
not simply a tuning matter, but I wanted to check here to see if
there are any known issues with compiler performance.

A couple of pieces of information that might prove useful are

  - he includes windows.h, which apparently brings a lot of other
    include files in, and

  - he is compiling against software provided by a company named 
    Bristol.  He claims that Bristol has reported slow compile performance
    to Digital in the past.

Thanks,

Jerry

P.S.  On the bright side, the customer was complimentary in regard to the
code that is being generated by 5.4.
T.RTitleUserPersonal
Name		DateLines
3425.1BEGIN::ROTITHORMon Feb 03 1997 13:104
What is the customer comparing the compile time performance of v5.4 with?
What compile time switches are used?
If you can proviede us with a source file that particularly takes long time to
compile we can analyze the case.
3425.2maybe a clue...CSC32::P_MILLSSisyphus did telephone support.Mon Feb 03 1997 15:428
    Jerry's customer logged a call to us on the internals side. 
    The compiler isn't the sole source of ills here. It's running
    on an as400 with 64 meg. They're out of memory, overloading
    the swapfile space, and overloading the pagefile space. We
    would call 64 meg, in the real world, a "marginal" configuration.
    More page and swapfile space *may* keep the ox out of the ditch.
    Take 10 or so concurrent c/fortran compiles and add one c++ compile
    and results could be less than optimal.
3425.3thanksCSC32::J_HENSONDon't get even, get ahead!Tue Feb 04 1997 09:1623
>>     <<< Note 3425.2 by CSC32::P_MILLS "Sisyphus did telephone support." >>>
>>                              -< maybe a clue... >-

>>    Jerry's customer logged a call to us on the internals side. 
>>    The compiler isn't the sole source of ills here. It's running
>>    on an as400 with 64 meg. They're out of memory, overloading
>>    the swapfile space, and overloading the pagefile space. We
>>    would call 64 meg, in the real world, a "marginal" configuration.
>>    More page and swapfile space *may* keep the ox out of the ditch.
>>    Take 10 or so concurrent c/fortran compiles and add one c++ compile
>>    and results could be less than optimal.

Actually, this is what I was hoping to see.  My initial question was
mostly to see if there were any known issues with compiler performance.
I don't take enough c++ calls to be that familiar with it.

Now that the customer knows that at least part of his problems are
due to factors external to the compiler, I will hold off pursuing
this until the customer has addressed that situation.

Jerry

P.S.  Thanks, P.J.
3425.4potential memory hogCAIRN::HARRISKevin Harris, dtn 381-2039Tue Feb 04 1997 11:4817
Jerry,
	The C++ language lends itself to very high memory use during
compilation.  This is especially true with heavy use of inlining, deep class
heirarchys, and heavy use of templates.  In a marginal memory situation, the C++
compiler can definitely be the straw that breaks the camel's back.  On the
other hand, standalone compiling on a system as described above should not
overburden the system.

	We're in the process of obtaining copies of the Bristol products to use
in compile-time studies.  We may discover places where the compiler is using
excessive memory or CPU time, so don't blame it on the user too readily.

	Even if we're successful in getting the Bristol product, we'll need real
customer apps to test it with, so feel free to encourage the customer to send
in his example.  Please provide all relevant OS/compiler/Bristol version info,
of course.  Thanks!
		-Kevin