dkrupp added a comment. Thanks.
> It would be best to just add the scan-build-py support to the tree, > especially, since the new scrips are not tested. OK. We will update this patch with the scan-build-py changes and remove the ctu-build.py and ctu-analyze.py scripts. > I am curious which optimization strategies you considered. An idea that @NoQ > came up with was to serialize only the most used translation units. Another > idea is to choose the TUs that a particular file has most dependencies on and > only inline functions from those. Both of these strategies could work in practice, we did not try them. We implemented the two extremes: serialize all TUs/don't serialize any of the TUs. Both of them could can be useful in practice as is (depending if the user is cpu/memory/disk space bound). I think we could try with the above suggested optimizations as an incremental improvement (and keep this initial patch as simple as possible). > What mode would you prefer? Would you pay the 20%-30% in speed but reduce the > huge disk consumption? That might be a good option, especially, if you have > not exhausted the ideas on how to optimize. In this initial version I think we should keep the serializing mode. We just measured that the heap consumption of the non-serializing mode and it seems to be ~50% larger. Probably because the serializing mode only loads those AST fragments from the disk that is imported. But I can imagine that some user still want to use the non-serializing version which is not using extra disk space. So we will add the non-serializing mode in a next patch as an Analyzer option first (which we can turn into default behaviour later on). OK? > I see some changes to the compiler proper, such as ASTImporter, ASTContext, > SourceManager. We should split those changes into a separate patch and ask > for review from people working on those components. You can point back to > this patch, which would contain the analyzer related changes, and state that > the other patch is blocking this work. Allright, we will do that. So is it OK to proceed like this? https://reviews.llvm.org/D30691 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
