Use regex-lite instead of Regex

[RossSmyth]

Switches to using regex-lite rather than Regex. This improve comile time significantly as Regex is pretty chonky, and the regex is not used in a performance critical (imo) area.

My computer is a Windows 10 laptop with an i7-12800H. With rustc 1.77.0, compiling the tests & the rlib.

Release Builds

Regex

> rmdir -r -Force target
> Measure-Command { cargo test --no-run -r }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 42
Milliseconds      : 792
Ticks             : 427928612
TotalDays         : 0.00049528774537037
TotalHours        : 0.0118869058888889
TotalMinutes      : 0.713214353333333
TotalSeconds      : 42.7928612
TotalMilliseconds : 42792.8612

> rmdir -r -Force target
> Measure-Command { cargo build -r }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 12
Milliseconds      : 96
Ticks             : 120962426
TotalDays         : 0.00014000280787037
TotalHours        : 0.00336006738888889
TotalMinutes      : 0.201604043333333
TotalSeconds      : 12.0962426
TotalMilliseconds : 12096.2426

Regex-Lite

> rmdir -r -Force target
> Measure-Command { cargo test --no-run -r }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 30
Milliseconds      : 539
Ticks             : 305397015
TotalDays         : 0.000353468767361111
TotalHours        : 0.00848325041666667
TotalMinutes      : 0.508995025
TotalSeconds      : 30.5397015
TotalMilliseconds : 30539.7015

> rmdir -r -Force target
> Measure-Command { cargo build -r }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 4
Milliseconds      : 665
Ticks             : 46651654
TotalDays         : 5.39949699074074E-05
TotalHours        : 0.00129587927777778
TotalMinutes      : 0.0777527566666667
TotalSeconds      : 4.6651654
TotalMilliseconds : 4665.1654

Debug Builds

Regex

> rmdir -r -Force target
> Measure-Command { cargo test --no-run }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 10
Milliseconds      : 84
Ticks             : 100848322
TotalDays         : 0.000116722594907407
TotalHours        : 0.00280134227777778
TotalMinutes      : 0.168080536666667
TotalSeconds      : 10.0848322
TotalMilliseconds : 10084.8322
> rmdir -r -Force target
> Measure-Command { cargo build }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 4
Milliseconds      : 683
Ticks             : 46834151
TotalDays         : 5.4206193287037E-05
TotalHours        : 0.00130094863888889
TotalMinutes      : 0.0780569183333333
TotalSeconds      : 4.6834151
TotalMilliseconds : 4683.4151

Regex-Lite

> rmdir -r -Force target
> Measure-Command { cargo test --no-run }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 10
Milliseconds      : 251
Ticks             : 102519623
TotalDays         : 0.000118656971064815
TotalHours        : 0.00284776730555556
TotalMinutes      : 0.170866038333333
TotalSeconds      : 10.2519623
TotalMilliseconds : 10251.9623
> rmdir -r -Force target
> Measure-Command { cargo build }
...
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 3
Milliseconds      : 773
Ticks             : 37735125
TotalDays         : 4.36749131944444E-05
TotalHours        : 0.00104819791666667
TotalMinutes      : 0.062891875
TotalSeconds      : 3.7735125
TotalMilliseconds : 3773.5125

So it is much more important in release builds. But there are modest improvements in debug builds too. But I've worked hard to bring compilation times down in my app, and compiling Regex for this crate is currently the longest single crate in terms of wall-time.

[RossSmyth]

Those lints are either new or have been failing since before this PR. It is not in the scope of this PR to fix them.

[sirhcel]

Thank you very much for spotting this and looking for an alternative to the regex crate! The reduction in build time is even more impressive on my Windows machine in a sequential build:

• Release before and after

  >hyperfine --warmup 1 --prepare "cargo clean" "cargo build --release --jobs=1"
  Benchmark 1: cargo build --release --jobs=1
    Time (mean ± σ):     65.227 s ±  0.403 s    [User: 63.565 s, System: 2.110 s]
    Range (min … max):   64.595 s … 65.826 s    10 runs
  

  hyperfine --warmup 1 --prepare "cargo clean" "cargo build --release --jobs=1"
  Benchmark 1: cargo build --release --jobs=1
    Time (mean ± σ):     11.307 s ±  0.279 s    [User: 10.179 s, System: 0.819 s]
    Range (min … max):   11.132 s … 11.977 s    10 runs
  

• Debug before and after

  >hyperfine --warmup 1 --prepare "cargo clean" "cargo build --jobs=1"
  Benchmark 1: cargo build --jobs=1
    Time (mean ± σ):     25.999 s ±  0.503 s    [User: 23.733 s, System: 2.249 s]
    Range (min … max):   25.682 s … 27.217 s    10 runs
  

  >hyperfine --warmup 1 --prepare "cargo clean" "cargo build --jobs=1"
  Benchmark 1: cargo build --jobs=1
    Time (mean ± σ):      7.664 s ±  0.036 s    [User: 5.976 s, System: 1.077 s]
    Range (min … max):    7.627 s …  7.730 s    10 runs
  

Those lints are either new or have been failing since before this PR. It is not in the scope of this PR to fix them.

Yes, these lints look like they bubbled up with the latest Clippy. I tried to fix them here in the first place while missing out the MSRV conflict from regex-lite. Created #172 to clean this up.

We are currently using Rust 1.59 as MSRV as this is the version shipped with the latest long-term support release (LTS) Kirkstone of Yocto for building Linux distributions. But the next LTS version is about to be released in April and we can increase our MSRV then. Let me sleep over the how and when and I will go forward with integrating your PR soon.

[RossSmyth]

Okie dokie

[eldruin]

IIUC, it seems that the next Yocto LTS release (Scarthgap, due this month indeed) will ship Rust 1.75.0, which means we can also update nix (See #176).
Nevertheless, Kirkstone remains supported until April 2026 but waiting until then to upgrade our MSRV is untenable.

[sirhcel]

Superseded by #201! Thank you for your perseverance with this topic @RossSmyth!