It isn't uncommon for folks to debug programs with all the debug information for the whole system available. In those cases, what looks to the user like a normal sized application is actually a very large one as far as lldb's global string pool is concerned. My experience is that whenever you say "size of debug information"/"number of symbols" won't get larger than X, not very much time will generally show you wrong. So I'm leery of this change.
Jim > On May 3, 2017, at 3:04 PM, Scott Smith via Phabricator via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > scott.smith added a comment. > > Note, I don't expect you guys to want this as is, since the # of buckets > can't grow, and thus for very large applications this will behave O(n) > instead of O(1). Before I bother to convert this to 1M skip lists (instead > of 1M singly linked lists), is this something you're at all interested in? > It brings execution time of my test down from ~4.5s to ~3.5s (lldb -b -o 'b > main' -o 'run' my_test_program). > > > Repository: > rL LLVM > > https://reviews.llvm.org/D32832 > > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
