Hi all.

Each time I try to get back to work on LyX I am appalled by the
time it takes to compile and link.

I am currently trying (once more) to find an answer to the question
why LyX compilation and linking is so ridicously slow as it is 
right now (at least on *nix/automake).

Some external numbers: Out main application at work has about 6 times
the number of LOC as LyX yet compiles in about 70% of LyX's time.
So it is faster by a factor of about four(!) (on a full rebuild,
even more for null builds).

There are four main differences between both projects

 1. some parts (but not the bulk of the core) are C and FORTRAN,
 2. directory structure is flatter,
 3. files are larger on average,
 4. it's imake based.

We certainly do not want to switch over to FORTRAN. Point 4 is
not to interesting either as I certainly don't want a fourth
build system. Leaves 2 and 3. Playing around with 2 is strictly
no fun, so I had a shot at 3.

Testcase is src/graphics. Pretty selfcontained, modern C++ the
way we like it. A total of 2608 lines in 11 *.C files.

Status quo:

(plain g++)  touch *.C ; time make:  38.5 s
(ccache g++) touch *.C ; time make:   9.4 s
wc -c *.o: 4.36 MB

Now, cp *.C Graphics.C, adjust Makefile.am

(plain g++)  touch *.C ; time make:  15.2 s
(ccache g++) touch *.C ; time make:   0.26 s
wc -c *.o: 2.05 MB

So we can gain a factor of 2.5 on ordinary (re)compilation and
a factor of almost 60(!) in null builds, and save more than a
factor of two on diskspace.

What we currently do is most obviously not 'best practice'.

So as an immediate measure I propose to abondon the politics
of one class per .C/.h (or the even more ridiculous one of
one _function_ per file as seen in parts of src/support).

I the medium and long term I propose to merge self-contained
set of classes/functions/whatever into single translation
units.

A good starter would indeed be src/graphics as this is
a nice modular bit of code needing only a very slim interface.

Andre'

PS: On top of that, header files could be merged and the directory 
as a whole could vanish, speeding up make directory recursion.

PPS: Larger files are also easier to navigate with e.g. vi as
opposed to a directory containing several files, especially when
there is no file naming convention in place. So it should also
simplify maintanance if not used excessively.

Reply via email to