It uses about 56 MB less memory when LOOT launches into my Skyrim SE
large test load order with the latest masterlist and prelude, and
explicitly targets ECMAScript-like syntax like C++ std::regex does,
though supports newer functionality.
Compared to fancy-regex's syntax support, regress adds support for the
\0 nul character escape and removes support for:
- modifiers (e.g. `(?i)`)
- some Unicode character classes (e.g. used with `\p{}` and `\P{}`)
- the ASCII/POSIX character classes (e.g. `[:alpha:]`)
- various character escapes, including \A \a \z \b{start} \<
\b{end} \> \b{start-half} \b{end-half}
- (?P<name>exp) named capture groups
However, since regress's v flag requires more characters to be escaped
inside character classes than fancy-regex's Unicode support requires,
it's not used, so that further restricts the supported Unicode character
classes, and means that character class intersection, union and
subtraction syntaxes aren't supported.
The nul character escape is irrelevant for filename matching as it's not
allowed in Windows or Linux filenames.
Compared to C++ std::regex, the new restrictions are:
- the lack of support for ASCII/POSIX character classes
- the lack of support for control character escapes (e.g. `\cX`)
The lack of support for control character escapes is irrelevant as
control characters aren't allowed in Windows filenames.
A search of the masterlists doesn't find any use of the ASCII character
classes, and it's very unlikely that any user metadata would use them.
If such syntax is in use, it'll cause an error.
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.
Oliver Hamlet
dependabot[bot]andGitHub