improve efficiency (catch all)

[jtmoon79]

Summary

Improve efficiency either as CPU usage or Memory usage. This is a catch-all Issue for efficiency improvements that are too small to merit an individual Issue.

Current behavior

Some implementation could be faster.

Many of these areas are noted with code comment magic word cost-savings, like

// TODO: cost-savings: ...

For example,

pub(crate) fn captures_to_buffer_bytes(
    buffer: &mut [u8],
    // ...
    year_opt: &Option<Year>,
    // ...
) {
    // ...
    match year_opt {
        Some(year) => {
            // TODO: 2022/07/11 cost-savings: pass in `Option<&[u8]>`, avoid creating `String`
            let year_s: String = year.to_string();
            debug_assert_eq!(year_s.len(), 4, "Bad year string {:?}", year_s);
            defo!("using fallback year {:?}", year_s);
            copy_slice_to_buffer!(year_s.as_bytes(), buffer, at);
        }
    }
    // ...
}

Suggested behavior

Change the implementation to be faster or more efficient.

Other

These changes may violate recommended practice for when to optimize (too much work; too little gain).

[jtmoon79]

• [X] TODO: Look into new const-str features. Updated const-str in PR https://github.com/jtmoon79/super-speedy-syslog-searcher/pull/126

[jtmoon79]

Great article comparing thread memory usage. Apparently tokio is has very efficient memory-use for each thread.

[jtmoon79]

StringZilla looks promising. However, I'd need to review the flamegraph to see where it should be applied. I could apply it everywhere but that's a fair amount of work. So be little smarter about it.

Update: benchmarked here. Does well but is not as great as I hoped. memchr does better. Implemented in 55b8777a54b334efff499db31f8a3565837e25ee

[jtmoon79]

After https://github.com/chronotope/chrono/pull/1559 is implemented and released, then https://github.com/jtmoon79/super-speedy-syslog-searcher/blob/0.6.70/src/data/datetime.rs#L5002 should be faster and I don't think any changes will be necessary.

• [ ] verify chrono refactor of parsing is used in s4

[jtmoon79]

This comment moved to it's own Issue #288

---

A very worthwhile improvement is combining the multiple regular expressions for various numeric timezones into one regular expression. So instead of three regular expressions for timezone patterns +00:00, +0000, and +00, have one regular expression that handles those.

This would significantly reduce the number of hardcoded regular expressions reducing run-time and memory footprint, and simplify some of the code in datetime.rs https://github.com/jtmoon79/super-speedy-syslog-searcher/blob/0.6.70/src/data/datetime.rs#L2503-L2509

[jtmoon79]

• [X] Compile Regex on-demand 5ae0f033f00db93b45494ca7f0d93946e3633c63

[jtmoon79]

~pre-compile Regex~

looks like it's not possible to pre-compile a Regex.

The full story here really is not only a monumental amount of work, but it's not a one-time investment. By exposing a stable binary representation, it also makes internal evolution so much harder because any changes need to be reconciled with the binary format. I really just do not know if it will ever happen.

It's possible to pre-compile a DFA.

Moreover, regex-automata 0.2 (and especially 0.3 once it's released) will support serialization of regex DFAs.

However, DFA does not support capture groups.

This crate does not support sub-match extraction, which can be achieved with the regex crate's "captures" API. This may be added in the future, but is unlikely.