[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .cc files not including .h files
From: |
Rik |
Subject: |
Re: .cc files not including .h files |
Date: |
Mon, 1 May 2017 09:03:00 -0700 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: .cc files not including .h files,
Rik <=