lldb: do more than 1 kilobyte at a time to vastly increase binary sync speed

[russelltg]

Summary

https://github.com/llvm/llvm-project/issues/62750

I setup a simple test with a large .so (~100MiB) that was only present on the target machine
but not present on the local machine, and ran a lldb server on the target and connectd to it.

LLDB properly downloads the file from the remote, but it does so at a very slow speed, even over a hardwired 1Gbps connection!

Increasing the buffer size for downloading these helps quite a bit.

Test setup:

$ cat gen.py
print('const char* hugeglobal = ')

for _ in range(1000*500):
    print('  "' + '1234'*50 + '"')

print(';')
print('const char* mystring() { return hugeglobal; }')
$ gen.py > huge.c
$ mkdir libdir
$ gcc -fPIC huge.c -Wl,-soname,libhuge.so -o libdir/libhuge.so -shared
$ cat test.c
#include <string.h>
#include <stdio.h>
extern const char* mystring();
int main() {
        printf("%d\n", strlen(mystring()));
}
$ gcc test.c -L libdir -l huge -Wl,-rpath='$ORIGIN' -o test
$ rsync -a libdir remote:~/
$ ssh remote bash -c "cd ~/libdir && /llvm/buildr/bin/lldb-server platform --server --listen '*:1234'"

in another terminal

$ rm -rf ~/.lldb # clear cache
$ cat connect.lldb
platform select remote-linux
platform connect connect://10.0.0.14:1234
file test
b main
r
image list
c
q
$ time /llvm/buildr/bin/lldb --source connect.lldb

Times with various buffer sizes:

1kiB (current): ~22s
8kiB: ~8s
16kiB: ~4s
32kiB: ~3.5s
64kiB: ~2.8s
128kiB: ~2.6s
256kiB: ~2.1s
512kiB: ~2.1s
1MiB: ~2.1s
2MiB: ~2.1s

I choose 512kiB from this list as it seems to be the place where the returns start diminishing and still isn't that much memory

My understanding of how this makes such a difference is ReadFile issues a request for each call, and larger buffer means less round trip times. The "ideal" situation is ReadFile() being async and being able to issue multiple of these, but that is much more work for probably little gains.

NOTE: this is my first contribution, so wasn't sure who to choose as a reviewer. Greg Clayton seems to be the most appropriate of those in CODE_OWNERS.txt

[jasonmolenda]

Yeah that's an unintended bottleneck. If you're debugging to debugserver on a darwin system, it will tell lldb it uses a 128k max packet size, so larger read requests are still being broken up in to 128k chunks. The 128k size was set when we found little perf benefit from larger packet sizes. But using a 1k local buffer in this method to transfer binaries is unnecessary.

[russelltg]

Thanks for the reviews and approval. I don't have git access so if someone could push this that'd be fantastic.

[DavidSpickett]

Sure, what name and email address should go on the commit?

[russelltg]

Name: Russell Greene
Email: [e-mail]

Thank you :)

[DavidSpickett]

Done, thanks for the contribution!

lldb/source/Target/Platform.cpp

auto src_fd = OpenFile(src_file_spec, File::eOpenOptionReadOnly,
                          lldb::eFilePermissionsFileDefault, error);
 
   if (error.Fail()) {
     error.SetErrorStringWithFormat("unable to open source file: %s",
                                    error.AsCString());
     return error;
   }
 
-  std::vector<char> buffer(1024);
+  std::vector<char> buffer(512 * 1024);
   auto offset = src_offset;
   uint64_t total_bytes_read = 0;
   while (total_bytes_read < src_size) {
     const auto to_read = std::min(static_cast<uint64_t>(buffer.size()),
                                   src_size - total_bytes_read);
     const uint64_t n_read =
         ReadFile(src_fd, offset, &buffer[0], to_read, error);
     if (error.Fail())