diff options
author | Rui Ueyama <ruiu@google.com> | 2017-03-01 21:08:21 +0000 |
---|---|---|
committer | Rui Ueyama <ruiu@google.com> | 2017-03-01 21:08:21 +0000 |
commit | d0e07b919ca416cfa87af8d560241f903d12dbd3 (patch) | |
tree | 69658f98500a7571236d6909d3bf308ae3f5cf87 /lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py | |
parent | f78a6f084cc27b230d93ebeca091b0182e0ebc27 (diff) | |
download | bcm5719-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/expression_command/timeout/TestCallWithTimeout.py')
0 files changed, 0 insertions, 0 deletions