Hey, any chance you can post the latest version of you're patch? I'm interested in getting it checked on in. I have some time, and can work w/ dgregor and others to wrap up the serialization and benchmarking, etc.
On Fri, Jun 10, 2011 at 10:36 AM, Kaelyn Uhrain <[email protected]> wrote: > > > On Thu, Jun 9, 2011 at 6:34 PM, Chandler Carruth <[email protected]>wrote: > >> On Thu, Jun 9, 2011 at 6:18 PM, Kaelyn Uhrain <[email protected]> wrote: >> >>> Quick question about doing this: would it be more cost effective to use a >>> std::multimap to allow iterating through the namespaces in ascending order >>> of NNS length and exiting the loop once NNS length + edit distance are worse >>> than the best, or to use an llvm::SmallVector instead and always looping >>> over all of the namespaces, but skipping the lookup if (NNS length + ED) is >>> too long? >> >> >> Iterating over a std::map or std::multimap is rather slow. Why can't we >> just keep the SmallVector sorted by the NNS length? >> > > I had a feeling that was the case. The issue I'm having is in sorting the > NNSes by length--they vary based on the context of the typo correction, plus > the NNS, its length, and the DeclContext it points to have to remain > associated. Right now the list of known namespaces is a simple SmallPtrSet, > and the NNS and its length are calculated when needed--between when a symbol > is successfully looked up in a given DeclContext and when it is added with > its qualifier to the TypoCorrectionConsumer--and cached in a std::map for > the duration of the call to CorrectTypo (for use with other identifiers in > the same DeclContext). I'm not sure how the cost of calculating the > NestedNameSpecifiers for every namespace is affected by PCH files, but I'm > guessing the cost is less than what is saved by avoiding lookups in > namespaces stored in PCH files. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
