On Sat, Mar 24, 2007 at 09:33:47AM +0100, Andre Poenitz wrote:
>
> More data, mathed this time.
>
> 'Lumped' means a Mathed.C #include'ing everything else.
>
> Times are real/user/sys.
>
> Now Lumped
>
> Null build 2.6/1.4/0.9 1.6/1.3/0.3
>
> Full rebuild 154/132/12 48/ 44/ 1
>
> change MathParser.C 12/1.5/1 48/ 44/ 1
>
> So lumping everything together buys more than 30% in the common case of
> a Null and 60% for Full builds. The downside is when actually _working_
> on single files in mathed, where there's an increas of 300%.
>
> Given that there are 74 active .C files in mathed one approach might be
> to create smaller lumps of, say approx. 15 files each to get uniform
> improvement.
>
> I'll try that next.
Ok, just using MathedInsets.C for all insets and MathedCore.C for the
rest yields:
Now Lumped Lumped/2
Null build 2.6/1.4/0.9 1.6/1.3/0.3 1.2/1.2/0.1
Full rebuild 154/132/12 48/ 44/ 1 52/ 51/ 1
change MathParser.C 12/1.5/1 48/ 44/ 1 20/ 19/0.5
change InsetMath.C 34/ 33/0.5
wc -c *.o 22.6 MB 4.6 MB 5.5 MB
So there's clearly a trade-off here: We start already losing parts of
what we gained. Nevertheless, assuming the lumping is applied all
over LyX even a person working on mathed would already benefit as the
average of 17s lost weights against the gains for null builds in
the remaining ~19 source directories in LyX. On top of that comes the
gains in diskspace (75% here...) and quite likely faster linking
(no numbers for that so far, but I'd expect a 75% linker input size
reduction produce a similar effect on linker time - especially since
we know that GNU ld contains O(n^2) algorithms with n being the number
of symbols...)
So a new proposal now:
- Have one WhatEver.C per directory under src/ #include'ing the needed
.C files. Access these new files from src/Makefile.am
- Consolidate the remaining parts of the Makefile.am's in
src/Makefile.am
- add an empty 'src/Local.C' and references it from src/Makefile.am
- Ignore stuff outside src/ for now.
This is a uniform improvement on what we have now and could serve as
a base for further improvements.
People working on file Foo.C and Bar.C not happy with the slower
single-file build could simple add an '#include Foo.C' in Local.C and
remove/comment the correspoding line in their original location.
Later we can think about a single 'Big.C' #include'ing all the per-
directory lumps. That should yield optimal Null and Full build times.
Combined with the Local.C idea that should give also optimal performance
(within the explored domain) for 'real' work.
Comments?
Andre'
