Author: Russell Greene
Date: 2023-06-19T10:12:45Z
New Revision: 6947db2778e0f4799f5311bc80fe7963aa8409c6

URL: 
https://github.com/llvm/llvm-project/commit/6947db2778e0f4799f5311bc80fe7963aa8409c6
DIFF: 
https://github.com/llvm/llvm-project/commit/6947db2778e0f4799f5311bc80fe7963aa8409c6.diff

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

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

Reviewed By: clayborg, jasonmolenda

Differential Revision: https://reviews.llvm.org/D153060

Added: 
    

Modified: 
    lldb/source/Target/Platform.cpp

Removed: 
    


################################################################################
diff  --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index 2590197c7149b..4b5d21bede121 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1630,7 +1630,7 @@ Status Platform::DownloadModuleSlice(const FileSpec 
&src_file_spec,
     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) {


        
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to