note about the design of mx-op-defs.h

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

note about the design of mx-op-defs.h

Jaroslav Hajek-2
hi,

during my recent job optimizing the reduction functions, I couldn't
help noticing that any change within mx-inlines.cc triggered a
horrible compilation cascade in which more than half of liboctave and
liboctinterp was recompiled. Tracking the reason I found that
mx-inlines.cc is #included in mx-op-defs.h and this is in turn
included in many header files to provide declarations for various
operations.
For future development, it would be much better to separate the
declarative and executive parts of mx-op-defs.h and MArray-defs.h (and
more?). I bet this would also speed-up the compilation significantly.
Almost certainly not worth doing for 3.2, but rather a suggestion for
future 3.4/4.0 project.
Right now Octave compiles IMHO quite slowly. Although slow compilation
is kind of typical for C++, I still think that we could improve this
somewhat by sorting out issues like the above.

cheers

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

note about the design of mx-op-defs.h

John W. Eaton
Administrator
On 16-Feb-2009, Jaroslav Hajek wrote:

| during my recent job optimizing the reduction functions, I couldn't
| help noticing that any change within mx-inlines.cc triggered a
| horrible compilation cascade in which more than half of liboctave and
| liboctinterp was recompiled. Tracking the reason I found that
| mx-inlines.cc is #included in mx-op-defs.h and this is in turn
| included in many header files to provide declarations for various
| operations.
| For future development, it would be much better to separate the
| declarative and executive parts of mx-op-defs.h and MArray-defs.h (and
| more?). I bet this would also speed-up the compilation significantly.
| Almost certainly not worth doing for 3.2, but rather a suggestion for
| future 3.4/4.0 project.
| Right now Octave compiles IMHO quite slowly. Although slow compilation
| is kind of typical for C++, I still think that we could improve this
| somewhat by sorting out issues like the above.

I have no objections to doing this and would even consider doing it
for 3.2 since it should be a fairly straighforward change.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: note about the design of mx-op-defs.h

Jaroslav Hajek-2
On Mon, Feb 16, 2009 at 10:13 PM, John W. Eaton <[hidden email]> wrote:

> On 16-Feb-2009, Jaroslav Hajek wrote:
>
> | during my recent job optimizing the reduction functions, I couldn't
> | help noticing that any change within mx-inlines.cc triggered a
> | horrible compilation cascade in which more than half of liboctave and
> | liboctinterp was recompiled. Tracking the reason I found that
> | mx-inlines.cc is #included in mx-op-defs.h and this is in turn
> | included in many header files to provide declarations for various
> | operations.
> | For future development, it would be much better to separate the
> | declarative and executive parts of mx-op-defs.h and MArray-defs.h (and
> | more?). I bet this would also speed-up the compilation significantly.
> | Almost certainly not worth doing for 3.2, but rather a suggestion for
> | future 3.4/4.0 project.
> | Right now Octave compiles IMHO quite slowly. Although slow compilation
> | is kind of typical for C++, I still think that we could improve this
> | somewhat by sorting out issues like the above.
>
> I have no objections to doing this and would even consider doing it
> for 3.2 since it should be a fairly straighforward change.
>
> jwe
>

Fine, I've made this change. I have made no measurements but it is my
impression that liboctave compiles somewhat faster.

cheers

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: note about the design of mx-op-defs.h

John W. Eaton
Administrator
On 17-Feb-2009, Jaroslav Hajek wrote:

| Fine, I've made this change. I have made no measurements but it is my
| impression that liboctave compiles somewhat faster.

OK, thanks for making this change.

jwe