[Libreoffice] a faster gnumake ? ...
bjoern.michaelsen at canonical.com
Tue Apr 5 02:25:59 PDT 2011
On Tue, 05 Apr 2011 09:41:10 +0100
Michael Meeks <michael.meeks at novell.com>
> I wonder - if we had a single phony target for each file's
> dependencies, and a tree of these, instead of this 50Mb flattened
> monster blob; if that would be significantly faster [ and/or if it is
> even possible ]
In theory you could generate the direct dependencies for each header
file and cxx and make a nice tree from that. In practice, it has its
own set of problems:
- we have a lot more headers than cxx and you would have to track the
dependency file for each of those
- the dep tree would get a lot deeper by that alone
- this is context sensitive: header files might have different deps
depending on where it was included from as DEFINEs might toggle stuff
- generating the deps by the compiler is costing us almost nothing
currently, doing something like that for each header _will_ cost us.
- as long as we have headers in multiple locations ("deliver"), that
can lead to fun results too.
Thus that would introduce a lot of fragility and not be KISS at all.
Lets not forget the words of wisdom by the Don:
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
Remember also that sw already has 24000 include statements alone (about
1/7 of the whole product).(*)
IMHO if we want to solve this, we need to be honest to ourselves and
admit that this is only the symptom of the real problem that is is the
huge amount of includes we are using. A few of those might be sensible,
a few of them might be superfluous and a lot of them will only be solved
by better encapsulation in our codebase.
More information about the LibreOffice