size of librocksdb.a is too huge
979357361 opened this issue · comments
Hello guys, good day! I am here for help again...
I want to use rocksdb in my C program, and I prefer to static link.
I use <make -j static_lib> to compile the static lib, as a result I get a librocksdb.a file whose size is more than 1GB, this is too heavy, after link rocksdb, my program size goes to 300MB+ from 30MB, this seems unacceptable.
Could you please tell me how to slim the librocksdb.a? to be more exact, what could I do to slim my program?
thanks for your time, good day again~
by the way, when will the v9.2 release ready?
Hi @979357361 , have you tried stripping the librocksdb.a library after it was built?
Here are results from a local build of mine (x86_64, make static_lib), using latest RocksDB:
~/Downloads/rocksdb$ ls -al librocksdb.a
-rw-rw-r-- 1 jan jan 964174982 May 10 15:28 librocksdb.a
~/Downloads/rocksdb$ file librocksdb.a
librocksdb.a: current ar archive
~/Downloads/rocksdb$ strip librocksdb.a
~/Downloads/rocksdb$ ls -al librocksdb.a
-rw-rw-r-- 1 jan jan 14281184 May 10 15:28 librocksdb.a
~/Downloads/rocksdb$ file librocksdb.a
librocksdb.a: current ar archive
So running the strip command on the library in order to remove debug symbols reduced the library size from almost 1GB to only 14MB. Your mileage may vary, but I think stripping the library could be beneficial to reduce its size.
This obviously removes debug symbols, so this is not an option if you need them.
Hi @jsteemann, thanks for your time.
In my build, after [strip], compile will error with [undefined reference to xxxx (C API)], but the compile do work before strip, so is there something wrong?
another thing bothering me is that, [INSTALL.md] tell me that RocksDB's library should be able to compile without any dependency installed. I do not use compress in ROCKSDB, so there is n0 libzstd in my server, if I use [make -j static_lib] to build librocksdb.a, it works and I can compile my program and run it, but for librocksdb.so with cmd [make -j shared_lib], it goes wrong with "cannot find -lzstd", it seems unreasonable?
CC utilities/transactions/lock/range/range_tree/range_tree_lock_tracker.o
GEN util/build_version.cc
CC util/build_version.o
CCLD librocksdb.so.9.0.0
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lzstd
collect2: error: ld returned 1 exit status
make: *** [librocksdb.so.9.0.0] Error 1
@979357361 : I can't say much about building the shared library, because I never tried to do so myself.
Regarding stripping: if you link the RocksDB library to your executable, you can run strip on the resulting executable. Or, you can run strip with some selected options on the RocksDB library before linking to your executable. In this case, some of the symbols may need to remain for linking. You can check the specific options of the strip command and only have it strip specific sections (e.g. debug symbols) from the library. But I guess it is easier to run strip on the final executable, after linking.
In case you are wondering how large the sections in the library file are, you can try Google Bloaty to analyze the library file. In my case, it prints
$ bloaty librocksdb.a
FILE SIZE VM SIZE
-------------- --------------
33.9% 311Mi 0.0% 0 .debug_str
31.9% 293Mi 0.0% 0 .rela.debug_info
20.5% 188Mi 0.0% 0 .debug_info
3.6% 32.8Mi 0.0% 0 .rela.debug_loclists
3.4% 31.3Mi 0.0% 0 .debug_loclists
1.6% 14.4Mi 0.0% 0 .debug_line
1.0% 8.92Mi 47.3% 5.00Mi [11672 Others]
0.7% 6.63Mi 0.0% 0 .rela.debug_rnglists
0.5% 5.02Mi 0.0% 0 .debug_rnglists
0.5% 4.60Mi 43.5% 4.60Mi .text
0.4% 3.88Mi 0.0% 0 .strtab
0.4% 3.41Mi 0.0% 0 [ELF Section Headers]
0.2% 2.21Mi 0.0% 0 .debug_abbrev
0.2% 2.16Mi 0.0% 0 .rela.text
0.2% 2.14Mi 0.0% 0 [AR Symbol Table]
0.2% 1.96Mi 0.0% 0 .symtab
0.2% 1.84Mi 0.0% 0 .rela.debug_line
0.2% 1.80Mi 0.0% 0 .shstrtab
0.1% 993Ki 9.2% 993Ki .eh_frame
0.1% 901Ki 0.0% 0 .debug_line_str
0.1% 851Ki 0.0% 0 .rela.eh_frame
100.0% 919Mi 100.0% 10.6Mi TOTAL
But your mileage may vary.