summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorRui Ueyama <ruiu@google.com>2017-03-01 21:08:21 +0000
committerRui Ueyama <ruiu@google.com>2017-03-01 21:08:21 +0000
commitd0e07b919ca416cfa87af8d560241f903d12dbd3 (patch)
tree69658f98500a7571236d6909d3bf308ae3f5cf87 /lldb/packages/Python/lldbsuite/test
parentf78a6f084cc27b230d93ebeca091b0182e0ebc27 (diff)
downloadbcm5719-llvm-d0e07b919ca416cfa87af8d560241f903d12dbd3.tar.gz
bcm5719-llvm-d0e07b919ca416cfa87af8d560241f903d12dbd3.zip
Don't implement the gdb hash table as a generic in-memory hash table.
Looks like .gdb.index and its support classes do things that they don't have to or shouldn't do do. This patch addresses one of these issues. GdbHashTab class is a hash table class. Just like other in-memory hash tables, that incrementally updates its internal data and resizes buckets as new elements are added so that key lookup is always fast. But that is completely not necessary. Unlike debuggers, we only produce hash tables for .gdb.index and never read them. So incrementally updating a hash table in memory is just a waste of resource and complicates the code. What we should do is to accumulate symbols and then create the final hash table at once. llvm-svn: 296678
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud