Andre Poenitz wrote: > 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
when touching one file in debug mode I now get: insets/ExternalTemplate.C : 32 seconds mathed/InsetMathed.C : 24 seconds in release mode linking is faster and I get: insets/ExternalTemplate.C : 16 seconds mathed/InsetMathed.C : 12 seconds Are your change numbers minutes or seconds? Peter > > 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' > -- Peter Kümmel
