|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | gcj specific speedup for helpcontent2 building | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Build Tools | Reporter: | caolanm | ||||||||
| Component: | code | Assignee: | hjs <hans-joachim.lankenau> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> | ||||||||
| Severity: | Trivial | ||||||||||
| Priority: | P3 | CC: | bero, issues, ivo.hinkelmann, pavel, rene, sparcmoz | ||||||||
| Version: | 680m130 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux, all | ||||||||||
| Issue Type: | PATCH | Latest Confirmation in: | --- | ||||||||
| Developer Difficulty: | --- | ||||||||||
| Issue Depends on: | 61278 | ||||||||||
| Issue Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
caolanm
2005-09-16 12:25:05 UTC
Created attachment 29600 [details]
patch, testing in progress
don't know how this will play with system-db yet ihi cc'ed FWIW my results for (a pile of languages) on same parallel build box for build time from configure to start of install set creation and both builds with gcj are: without a native HelpLinker binary, 3 hours 40 minutes, with HelpLinker binary was 2 hours 45 minutes That 2:45 is larger than it might "really" be as it includes recovery from issue 54708 where a portion of sc was build linearly. Created attachment 29765 [details]
updated to be aware of system db option
Created attachment 31151 [details]
lastest version
Introduces issue #61278, but works perfectly and with a HUGE speedup after fixing that. done in targetedaot reopen for qaing So heres what the idea is. a) separate the concepts "gcj as compiler" from the "gcj" (aka GNU ClassPath) JDK and seperate that from using gcj in it's role as "native binary creater" (aka Ahead Of Time compilation AOT). This allows AOT to be used to create native binaries/libraries from the bytecode output of other compilers, e.g. ecj as well as gcj. In theory this would also allow native binaries to be made of jars created with Sun Java, though your mileage might vary there depending on the bug of the day, but someone with sun java can give it a try if they want. b) rather than *always* create native binary libs from all jars as we do currently when the java compiler is gcj we b.1) default to doing nothing unless --enable-gcjaot is specified to configure (i.e. JAVAAOTCOMPILER is set in the environment). b.2) only create such AOT binaries for the java helpers used during the build-time, i.e. HelpLinker and FCFGMerge. So an additional "AOTTARGET" target achieves this. done in "targetedaot" writing to solver is bad . plan b cmc->hjs: how about now. No direct writing into the solver. The filter changes are rolled back so as to not conflict with the delivered xmlhelp stuff. filter java-side speedups are irrelevent for me really, xsltproc is the way to go there. rejigged can't we move the AOTTARGETN stuff from tg_jar.mk to xmlhelp and give it a comment that the solver jar handling must be changed before duplicating/centralizing? just a small change to make me happy too ;) how about now, moved into aottarget.mk locally in the xmlhelp dir which created HelpLinker In my system JAVAAOTCOMPILER is exported to the environment like @JAVAAOTCOMPILER@ probably because single quotes ' instead of double quotes " around @JAVAAOTCOMPILER@ in set_soenv.in good catch, fixed . . |