lldb compiled from source 5X slower than homebrew or default lldb

while testing out https://github.com/llvm-mirror/lldb/pull/3 I noticed
that when I compiled lldb from source (even un-modified from git HEAD)
it was 5X slower than homebrew lldb or default lldb:

I'm compiling lldb as follows:

git clone https://github.com/llvm-mirror/llvm.git
cd llvm/tools
git clone https://github.com/llvm-mirror/lldb
## also, patch in https://github.com/llvm-mirror/lldb/pull/3
git clone https://github.com/llvm-mirror/clang
cd ..
mkdir build
cd build
ccmake .. -G Ninja
# here I set: CMAKE_BUILD_TYPE      Release
ninja all

I also tried setting `LLVM_ENABLE_ASSERTIONS OFF` but no difference

commands.txt

b FOO
r
bt
q

./test is some program i have.

time lldb -s commands.txt -- ./test
8 seconds
time ./build/bin/lldb -s commands.txt -- ./test
40 seconds

Have you tried diff'ing your cmake invocation against the on used by homebrew?

-- adrian

after further inspection it turns out it's a performance regression
between llvm 5 and llvm 6:

$homebrew_D/Cellar/llvm/5.0.1/lldb -s test_lldb.txt -- prog
8 seconds
$homebrew_D/Cellar/llvm/6.0.0/bin/lldb -s test_lldb.txt -- prog
40 seconds

cat test_lldb.txt:

b FOO
r
bt
q

prog is some binary I'm debugging. It's unfortunately hard to reduce.
What are good ways to investigate this?

If this is a Mac I would recommend to build both lldbs in RelWithDebInfo mode and then run them through Instruments and compare the traces. I'd be very interested in learning what the cause for the slowdown is.

-- adrian

I would start by looking at https://reviews.llvm.org/D32598, which adds a bunch of work we do up-front. I remember looking at this a while back and not being sure whether all of that work is relevant for osx, actually. (I’m specifically thinking of the SymbolFileDWARF::Index call, which is done unconditionally, but I think that index is unused if we have accelerator tables).

Good catch Pavel, I missed that part where it calls Index manually even if we have accelerator tables where we don’t need to manually index.

We should modify SymbolFileDWARF::Index() that currently looks like:

void SymbolFileDWARF::Index() {
if (m_indexed)
return;

}

To look like:

bool SymbolFileDWARF::HasFullIndex() const {
return m_using_apple_tables;
}

void SymbolFileDWARF::Index() {
if (m_indexed || HasFullIndex())
return;


}

SymbolFileDWARF::HasFullIndex() is a new function we need to add. Then as we update LLDB to handle new accelerator tables, like the new DWARF 5 tables Pavel is working on getting checked into LLVM and LLDB, we can update SymbolFileDWARF::HasFullIndex() as needed. This should return the high performance on systems with full accelerator tables. Let us know if this works.

Greg Clayton