It too slow to generate dSYM file, when project is big.
Debug show that MainBinarySymbolAddresses.size() is 2,643k;
I replace linear lookup with a map to speed it up;
In my project it took 2.5 minutes than 30 minutes before.
Differential D121006
Speedup dsymutil when working with big project. C-_-fan on Mar 4 2022, 9:07 AM. Authored by
Details
It too slow to generate dSYM file, when project is big. I replace linear lookup with a map to speed it up;
Diff Detail
Unit Tests Event TimelineComment Actions This only becomes a problem when you have a huge number of public symbols. I bet the majority of these symbols are weak exports from linkeonce_odr functions. Could you change your project to use something like -fvisibility=hidden to hide symbols by default? Doing that has the added benefit of saving the dynamic loader a bunch of work and improving launch time. I ran some benchmarks on clang, and indeed, this patch actually slows things down: Baseline: Time (mean ± σ): 86.446 s ± 0.274 s [User: 124.955 s, System: 4.702 s] Range (min … max): 86.075 s … 86.932 s 10 runs With this patch: Time (mean ± σ): 88.012 s ± 0.502 s [User: 127.594 s, System: 5.156 s] Range (min … max): 87.397 s … 89.001 s 10 runs
Comment Actions I am abandoned the change about rfind, and replaced std::unordered_map<uint64_t, std::vector<StringRef>> with SmallDenseMap<uint64_t, SmallVector<StringRef>>; In my test, now it take more time because rfind performance rollback; but SmallDenseMap and SmallVector is fast than unordered_map and vector. I will try -fvisibility=hidden next week. Please reivew it agagin. If can not merge still, how can I close this revision? Or this will close auto after timeout? Thanks again. Comment Actions Whether or not can I find a threshold to divide the code into 2 branches? One branch is use to processing the normal project and the other one is use to processing the overlong project. Comment Actions I just came in to comment on the API change — seems like ArrayRef would be better! — but a spotted a couple of other things. (I don't have much context on the logic here in dsymutil, so these are just suggestions; probably @JDevlieghere or @lebedev.ri will need to LGTM; but thought I'd share what I noticed.)
|
I'm not sure I understand what this is trying to achieve. Changes to support should go in a separate patch with its own description/motivation and unit test coverage.