Peter Kümmel wrote: > 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 >
And I don't have a fast system: 1GHz, Athlon XP, [EMAIL PROTECTED] (it's a down-clocked 1.6 GHz System) > > 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
