libloot's C++ implementation is licensed under the GPL v3.0 or later, not v3.0 only, so carry the same into the Rust reimplementation and its dependent crates.
The cargo profile in the nodejs folder gets ignored because the crate is in a workspace, but it got me thinking about LTO.
Enabling fat LTO more than doubles the build time, and although it shrinks the binary size, if there is a performance impact it's not very obvious (based on sorting in LOOT with the built DLL). On the other hand, thin LTO only only adds a second to the cargo build time and reduced binary size by ~ 1.4 MB, and adding /LTCG on top reduces it by another ~ 1.6 MB. MSVC doesn't output how long linking takes, but it seemed to only add a second or two.
Include limited debug info in release builds to help with profiling.
Also add another profile that's equivalent to CMake's RelWithDebInfo.
Testing suggests that although it uses a lower opt-level, it might
actually perform better (at least on Windows), though the differences
are only ~ 100 ms in startup and sorting times.
The default std hasher is DoS-resistant but relatively slow, and
DoS-resistance isn't a useful property during sorting.
I tested using the rustc-hash, fnv and ahash crates against my
1600-plugin load order, and the results vs the default std hasher
were:
- AHash: 31% faster
- FNV: 33% faster
- FxHasher (from rustc-hash): 37% faster
With the std hasher the Rust libloot is 35% slower than C++, with
FxHasher it's 15% faster.
Oliver Hamlet