vsk added a comment. In D20401#2770059 <https://reviews.llvm.org/D20401#2770059>, @nickdesaulniers wrote:
> I know this was sped up slightly in 3339c568c43e4644f02289e5edfc78c860f19c9f, > but this change makes `updateConsecutiveMacroArgTokens` the hottest function > in clang in a bottom up profile of an entire build of the Linux kernel. It > thrashes the one entry LastFileIDLookup cache, and we end up looking up the > same FileID again and again and again for each token when we expand nested > function like macros. > > Is there anything we can do to speed this up? Is there any way to record > which FileID corresponds to a given Token so that we don't have to keep > rematerializing that? Is it possible to find whether two SourceLocations > correspond to the same FileID without having to figure out which FileID in > particular each belongs to? Perhaps you could try: - using SourceManager::isInFileID(NextLoc, getFileID(CurLoc), ...) (to halve the number of necessary getFileID lookups), or - using a 2-element cache in getFileID? >> I discussed this bug with Argyrios off-list, who lgtm'd on the condition >> that it doesn't introduce a performance regression. > > Well, I'd say it's a performance regression, though perhaps reported 5 years > too late. If the performance issue manifests on Linux kernel sources from 5 years ago, then sure, I'd agree :). Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D20401/new/ https://reviews.llvm.org/D20401 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
