From b0572abf72fd4aafbb56bc41350e41bdfd96cdde Mon Sep 17 00:00:00 2001 From: Greg Clayton Date: Tue, 1 Jun 2021 21:52:31 -0700 Subject: Improve performance when parsing symbol tables in mach-o files. Some larger projects were loading quite slowly with the current LLDB on macOS and macOS simulator builds. I did some instrument traces and found 3 main culprits: - a LLDB timer that was put into a function that was called too often - a std::set that was keeping track of the address of symbols that were already added - a unnamed function generator in ObjectFile that was going slow due to allocations In order to see this in action I ran the latest LLDB on a large application with many frameworks using the following method: (lldb) script import time; start_time = time.perf_counter() (lldb) file Large.app (lldb) script print(time.perf_counter() - start_time) I first range "sudo purge" to clear the system file caches to simulate a cold startup of the debugger, followed by two iterations with warm file caches. Prior to this fix I was seeing the following timings: 17.68 (cold) 14.56 (warm 1) 14.52 (warm 2) After this fix I was seeing: 11.32 (cold) 8.43 (warm 1) 8.49 (warm 2) Differential Revision: https://reviews.llvm.org/D103504 --- lldb/source/Core/Module.cpp | 2 -- 1 file changed, 2 deletions(-) (limited to 'lldb/source/Core/Module.cpp') diff --git a/lldb/source/Core/Module.cpp b/lldb/source/Core/Module.cpp index 117b0bfd5aae..64193b57b095 100644 --- a/lldb/source/Core/Module.cpp +++ b/lldb/source/Core/Module.cpp @@ -440,8 +440,6 @@ CompUnitSP Module::GetCompileUnitAtIndex(size_t index) { bool Module::ResolveFileAddress(lldb::addr_t vm_addr, Address &so_addr) { std::lock_guard guard(m_mutex); - LLDB_SCOPED_TIMERF("Module::ResolveFileAddress (vm_addr = 0x%" PRIx64 ")", - vm_addr); SectionList *section_list = GetSectionList(); if (section_list) return so_addr.ResolveAddressUsingFileSections(vm_addr, section_list); -- cgit v1.2.3