Say how to link the collocation database statically
The speed comes from linking rocksdb and collocatordb statically, not from a
completely static binary, which additionally needs static system libraries that
Rocky Linux, RHEL and Fedora do not ship. Pointing the build at the two static
libraries is enough and makes indexing about 22% faster.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I41d6f9a532670b821e1938d98f1fc10afc497bb0
diff --git a/README.md b/README.md
index 7815a72..1d78a3e 100644
--- a/README.md
+++ b/README.md
@@ -25,14 +25,23 @@
This installs `dereko2vec` and `vecs2mmap`. The build directory has to be
`build` inside the sources, the test looks for the binary relative to it.
-A completely static `dereko2vec` is about 10% faster on the collocator database
-and needs a static rocksdb and a static collocatordb:
+### Faster indexing
+
+Linking rocksdb and collocatordb statically makes counting collocations about
+22% faster, measured with 2 million increments against rocksdb 7.8.3. On an
+indexing run of two weeks that is about three days. Point the build at the
+static libraries, the compression libraries stay shared:
```bash
-cmake -DSTATIC_DEREKO2VEC=ON ..
+cmake -DCOLLOCATORDB=/usr/local/lib64/libcollocatordb_static.a \
+ -DROCKSDB=/path/to/librocksdb.a ..
```
-Debian and Ubuntu ship `librocksdb.a` in `librocksdb-dev`. Fedora, Rocky Linux
+This does not need static versions of zlib, snappy, lz4 and zstd, which Rocky
+Linux, RHEL and Fedora do not ship. Only `-DSTATIC_DEREKO2VEC=ON`, which builds
+a completely static binary, needs those, and is rarely worth the trouble.
+
+Debian and Ubuntu have `librocksdb.a` in `librocksdb-dev`. Fedora, Rocky Linux
and RHEL do not, the
[collocatordb README](https://korap.ids-mannheim.de/gerrit/plugins/gitiles/ids-kl/collocatordb)
says how to build one there without shadowing the headers of the package.