[core] ACLiC: speed up building / loading: #8017
Conversation
|
I'll clean up git history once the tests pass - there's root-project/roottest#699 and the very different projectroot.core.metacling.test.gtest_core_metacling_test_TClingTest |
|
Loading a library that is needed to resolve symbols (as done by this PR) means that libraries linked against that library are loaded as a side-effect, without TCling / TSystem seeing it. TClingTest's |
Axel-Naumann
force-pushed
the
ACLiC-do-not-walk-all-libs-for-U-syms
branch
2 times, most recently
from
8c1ed58 to
c08b2da
Compare
When loading an existing ACLiC library, and if we expect it to contain the dependencies (explicit linking), just load it, instead of trying to (re-)determine its dependencies from its undefined symbols: the outcome should be just the library dependencies we expect the library to know already. For the (rare) non-explicit-linking case, continue to find and load all dependent libraries. Way slower, but also way rarer.
Axel-Naumann
force-pushed
the
ACLiC-do-not-walk-all-libs-for-U-syms
branch
from
c08b2da to
ed10012
Compare
| if (!keep) k->SetBit(kMustCleanup); | ||
| fCompiled->Add(k); | ||
|
|
||
| gInterpreter->GetSharedLibDeps(library); |
There was a problem hiding this comment.
This call is still needed for the not-explicitly-linked case. It has the side effect of load the dependencies from the rootmap files so that the subsequent LoadLibrary can use that information. See commit 8fdd5c3
There was a problem hiding this comment.
Related we should probably deprecate the option to disable explicit linking in ACLiC (it is already removed from the main build). Eitherway removing this line probably require to add (or check we already have) a test for the problem solved by commit 8fdd5c3
pcanal
left a comment
pcanal
left a comment
There was a problem hiding this comment.
Approved but need one more correction.
|
Other speedup related issues: |
Test Results 17 files 17 suites 4d 3h 48m 11s ⏱️ Results for commit ed10012. ♻️ This comment has been updated with latest results. |
6 participants
Instead of looking for libraries resolving each unresolved symbol,
just load each lib resolving symbols: this will allow subsequent
missing symbols to be resolved from the loaded library quickly,
without touching disk.
When loading an existing ACLiC library, and if we expect it
to contain the dependencies (explicit linking), just load itt,
instead of trying to (re-)determine its dependencies from its
undefined symbols: the outcome should be just the library
dependencies we expect the library to know already.