On 21 December 2017 at 10:45, Pavel Labath <lab...@google.com> wrote:
> I'm not sure now whether you're suggesting to use the dsymutil
> approach just to gauge the potential speedup we can obtain and get
> people interested, or as a productized solution. If it's the first one
> then I fully agree with you. Although I think I can see an even
> simpler way to estimate the speedup: build lldb for mac with apple
> indexes disabled and compare its performance to a vanilla one. I'm
> going to see if I can get some numbers on this today.
Here's some data I gathered today. What I did was I disabled apple
accelerator table parsing in ObjectFileELF (patch is in the
attachment) and then I compared startup time when debugging lldb with
itself. Specifically I used an Release (optimized) lldb to open a
Debug lldb, set a breakpoint, hit it, display local variables and
backtrace. The precise command is:
$ time opt/bin/lldb -o "br set -n DoExecute" -o "pr la" -o "bt" -o "fr
var" -b -- dbg/bin/lldb -- /bin/ls
I ran the command three times and chose the median result.
Before I show the measurements I have to give one big disclaimer: The
debugger with accelerator tables disabled does not appear to be fully
functional. Specifically most (all?) of the objc tests in the test
suite hang, and also 50 additional tests fail (the failures seem to be
related to expression evaluation, mostly). However, I think the fact
that the remaining ~2000 tests passed means that we still have been
reading the dwarf parsing functionality is reasonably intact.
Now, the numbers:
vanilla dSYM
real 0m7.774s
user 0m15.261s
sys 0m1.228s
=====
vanilla no-dSYM
real 0m5.987s
user 0m4.919s
sys 0m0.698s
=====
no-apple dSYM
real 0m7.616s
user 0m14.812s
sys 0m1.208s
=====
no-apple no-dSYM
real 0m45.520s
user 0m31.096s
sys 0m11.101s
It's not fully clear to me how to interpret this data. The difference
between having the accelerator tables and not is approximately what I
would expect (a lot) in the no-dSYM scenario, and I believe this is
the kind of speedup we should expect on linux. However, there are also
some question marks, like why is the time virtually unchanged in case
we have a dSYM bundle around? Also, the difference between having dSYM
and not is quite large (and opposite to what I would expect) in
"vanilla" case.
diff --git a/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f149ec354..3be8fe7cb 100644
--- a/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -447,46 +447,6 @@ void SymbolFileDWARF::InitializeObject() {
if (section)
m_obj_file->ReadSectionData(section, m_dwarf_data);
}
-
- get_apple_names_data();
- if (m_data_apple_names.m_data.GetByteSize() > 0) {
- m_apple_names_ap.reset(new DWARFMappedHash::MemoryTable(
- m_data_apple_names.m_data, get_debug_str_data(), ".apple_names"));
- if (m_apple_names_ap->IsValid())
- m_using_apple_tables = true;
- else
- m_apple_names_ap.reset();
- }
- get_apple_types_data();
- if (m_data_apple_types.m_data.GetByteSize() > 0) {
- m_apple_types_ap.reset(new DWARFMappedHash::MemoryTable(
- m_data_apple_types.m_data, get_debug_str_data(), ".apple_types"));
- if (m_apple_types_ap->IsValid())
- m_using_apple_tables = true;
- else
- m_apple_types_ap.reset();
- }
-
- get_apple_namespaces_data();
- if (m_data_apple_namespaces.m_data.GetByteSize() > 0) {
- m_apple_namespaces_ap.reset(new DWARFMappedHash::MemoryTable(
- m_data_apple_namespaces.m_data, get_debug_str_data(),
- ".apple_namespaces"));
- if (m_apple_namespaces_ap->IsValid())
- m_using_apple_tables = true;
- else
- m_apple_namespaces_ap.reset();
- }
-
- get_apple_objc_data();
- if (m_data_apple_objc.m_data.GetByteSize() > 0) {
- m_apple_objc_ap.reset(new DWARFMappedHash::MemoryTable(
- m_data_apple_objc.m_data, get_debug_str_data(), ".apple_objc"));
- if (m_apple_objc_ap->IsValid())
- m_using_apple_tables = true;
- else
- m_apple_objc_ap.reset();
- }
}
bool SymbolFileDWARF::SupportedVersion(uint16_t version) {
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
