Re: .cc files not including .h files

[Rik]

On 04/30/2017 08:43 PM, Daniel J Sebald wrote:
> On 04/28/2017 11:34 AM, Rik wrote:
>> jwe,
>>
>> I didn't really want to get in to the mess of streamlining the header
>> files, but I stumbled upon data.cc in libinterp/corefcn which does not
>> include data.h.  This seems odd as the pattern is that a file XXX.cc
>> include XXX.h if such a header file is available.  I wrote a short Perl
>> script to check this, and, for the libinterp directory, I see the following
>> cc files don't include the equivalently named header file.
>>
>> data.cc
>> defaults.cc
>> ft-text-renderer.cc
>> mex.cc
>> oct-hdf5-types.cc
>> toplev.cc
>>
>> Seems like something that should be reviewed and maybe a comment made if
>> this is correct.  For example, mex.h is a C-only include file.  However,
>> there is already a note there that says it should not be included in
>> mex.cc.
>>
>> --Rik
>
> If you are looking at header files, there is one thing I'm wondering
> about.  Is there a large amount of in-line code in the header files?
> I.e., routines for which the code exists in the header file rather than
> in the C++ proper files?  Typically, in-line functions are ones that
> should be very short, just a few instructions--functions so short that
> setting up the stack and passing variables makes it less efficient than
> just calling a few instructions when translated to assembly are still small.

That is correct.  There is some code in some header files, but it is all
generally very short and appropriate for inlining.  It might not hurt to do
a casual review while looking at the header files, but for the most part
the code already has been vetted and appropriately partitioned into .h and
.cc files.

>
> The reason I ask has to do with the speed of compilation.  I find working
> with source code (as opposed to modifying the script files) to be rather
> slow.  Making a small change in some C++ file requires minutes of
> compilation and linking.  What I'm wondering is if header files are
> included, with a long compilation associated with each header file and
> every time the header file is included.  Or are there pre-compiled headers?
>

I think this is just the nature of the beast.  An interpreted language is
great for Rapid Application Development (RAD) because there is no
compilation step.  It is very quick to run through the design/build/test
loop.  But, interpreted languages don't have the performance that a
compiled language does.

I recommend that you install and use ccache if you are developing for
Octave.  It cuts down my compilation times a lot.  I thought there was
something about this in the Octave manual or on the Octave wiki for
developers, but I'm not finding it now.  At OctConf 2015 I did some
benchmarking with Doug's new 8-core laptop.

Tests done on Doug's 8-core laptop at OctConf 2015.

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

Touch 1 file    
   
real     1m59.119s    
user     2m37.076s    
sys     0m5.928s    

   
   
make all    
   
real     8m52.424s    
user     55m31.676s    
sys     1m41.932s    

   
--------------------------------------------------------------------------------
With ccache    
   
Touch 1 file    
   
real     0m22.957s    
user     0m20.440s    
sys     0m2.904s    

   
   
make all    
   
real     2m8.961s    
user     3m6.964s    
sys     0m16.844s


For the use case you describe where you touch a single file and then
re-make Octave the compilation dropped from 2:37 to 0:20 or about 8X
faster.  For a full rebuild it changed from 55 minutes to 3 minutes.

--Rik