This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Speed up looking for dSYM next to executable
AbandonedPublic

Authored by bulbazord on Apr 24 2023, 1:12 PM.

Details

Summary

The goal of this patch is to speed up the code that searches for a dSYM
next to an executable.

I generated a project with 10,000 c source files and accompanying header
files using a script that I wrote. I generated objects for each of them
(with debug info in it) but intentionally did not create a dSYM for
anything. I also built a driver, and then linked everything into one
binary. The project itself is very simple, but the number of object files
involved is very large. I then measured lldb's performance debugging
this binary. (NB: I plan on putting this script into lldb's script
directory at some point after some cleanups)

Using the command lldb -x -b -o 'b main' $binary (launch lldb with no
lldbinit, place a breakpoint on main, and then quit), I measured how
long this takes and measured where time was being spent.

On my machine, I used hyperfine to get some statistics about how long
this actually took:

alex@alangford many-objects % hyperfine -w 3 -- "$lldb -x -b -o 'b main' $binary"
Benchmark 1: $lldb -x -b -o 'b main' $binary
  Time (mean ± σ):      4.395 s ±  0.046 s    [User: 3.239 s, System: 1.245 s]
  Range (min … max):    4.343 s …  4.471 s    10 runs

Out of the ~4.4 seconds of work, it looks like ~630ms were being spent
on LocateDSYMInVincinityOfExecutable. After digging in further, we
were spending the majority of our time manipulating paths in FileSpec
with RemoveLastPathComponent and AppendPathComponent. There were a
lot of FileSystem operations as well, so I made an attempt to minimize
the amount of calls to Exists and Resolve as well.

Given how widely used the code in FileSpec is, I opted to improve this
codepath specifically rather than attempt to refactor the internals of
FileSpec. I believe that improving FileSpec is also worth doing, but as
it is a larger change with far reaching implications, I opted to make
this change instead.

With this change, we shave off approximately 600ms:

alex@alangford many-objects % hyperfine -w 3 -- "$lldb -x -b -o 'b main' $binary"
Benchmark 1: $lldb -x -b -o 'b main' $binary
  Time (mean ± σ):      3.822 s ±  0.056 s    [User: 2.749 s, System: 1.167 s]
  Range (min … max):    3.750 s …  3.920 s    10 runs

Diff Detail

Event Timeline

bulbazord created this revision.Apr 24 2023, 1:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2023, 1:12 PM
bulbazord requested review of this revision.Apr 24 2023, 1:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2023, 1:12 PM

Perhaps the right thing to do would be to try to do the larger FileSpec changes instead? The changes in Symbols::LocateExecutableSymbolFile can probably go in regardless though. We call Resolve on all the file specs in debug_file_search_paths on line 307, so no need to call Resolve twice.

mib added inline comments.Apr 27 2023, 1:47 PM
lldb/source/Symbol/LocateSymbolFile.cpp
89–91

Why do you need the first call to append ?

102–118

Is this extra dot on purpose ?

105–108

This part is a bit confusing ... may be a comment would help understand what we're trying to achieve here.

178–181

Same here ... this could use a comment to explain what we're doing.

bulbazord added inline comments.Apr 27 2023, 2:27 PM
lldb/source/Symbol/LocateSymbolFile.cpp
89–91

The code suggestion you've given doesn't work for 2 reasons:

  • llvm::sys::path::append only takes 4 Twine arguments, so this won't compile.
  • llvm::sys::path::append appends things as if they were paths. So for /bin/ls you'll end up with /bin/ls/.dSYM/Contents/Resources/DWARF instead of /bin/ls.dSYM/Contents/Resources/DWARF.
102–118

I wanted to distinguish between $parent_dir/CF.framework because what is the parent_dir in this case? I used 3 dots to indicate $some_path/CF.framework.

105–108

I'll add more to the comment.

178–181

Will add.

bulbazord updated this revision to Diff 517725.Apr 27 2023, 2:54 PM

Address @mib's comments

bulbazord marked 4 inline comments as done.Apr 27 2023, 2:54 PM
mib accepted this revision.Apr 27 2023, 3:22 PM

Thanks! LGTM!

This revision is now accepted and ready to land.Apr 27 2023, 3:22 PM

IMHO this is optimizing the wrong thing. If FileSpec is slow, then we should try to make that faster, instead of updating the different places it's used.

bulbazord abandoned this revision.May 2 2023, 3:09 PM

I'm going to see how we could potentially improve FileSpec's performance rather than go with this approach.