Improve performance

[o2sh]

Onefetch's performance isn't so good to say the least. Even if we rely heavily on other tools for core functionalities (language statistics, license detection, git information), the post processing done by Onefetch adds a "significant" overhead - Moving forward, will require specific benchmarks to account for performance gain/losses - But a quick test on a relatively large repo Linux can give us a first idea:

o2sh:~/dev/linux (master) $ time onefetch --> 0m34,531s
o2sh:~/dev/linux (master) $ time tokei --> 0m11,897s

To achieve good performance some fundamental changes have to be made. Doing that will take a while because it makes it necessary to replace some core abstractions. The good news is that improving or even replacing those abstractions will have other benefits beside improved performance.

---

There are three primary paths for improving performance:

1. Refactoring
2. Caching
3. Asynchronicity/Multi-threading

So aside from this overview, these changes will also be discussed independently, in dedicated issues.

[spenserblack]

What are your thoughts on switching this crate to edition = "2018"? It's necessary for the async fn syntax.

[o2sh]

What are your thoughts on switching this crate to edition = "2018"? It's necessary for the async fn syntax.

Done. We can definitely improve the response time by using this syntax on some of the "info line" functions.

[spenserblack]

To make sure both onefetch and tokei have the same size vs speed optimizations, you might want to compile onefetch with the same release profile as tokei.

[profile.release]
lto = "thin"
panic = "abort"

[spenserblack]

@o2sh When using tokei as a binary, which version are you running?
Here's what I'm getting.

tokei --version
# tokei 12.0.4 compiled with serialization support: json

time tokei ../linux
# roughly 26 seconds typically
time ./target/release/onefetch ../linux
# roughly 19 seconds typically

Using tokei installed from Crates.io, onefetch compiled with --release flag @ b1d9c22

[spenserblack]

Bumped some dependencies that report performance improvements in the release notes
#189
#194
#190

[o2sh]

@o2sh When using tokei as a binary, which version are you running?
Here's what I'm getting.

tokei --version
# tokei 12.0.4 compiled with serialization support: json

time tokei ../linux
# roughly 26 seconds typically
time ./target/release/onefetch ../linux
# roughly 19 seconds typically

Using tokei installed from Crates.io, onefetch compiled with --release flag @ b1d9c22

This is very strange, I'm also running the version 12.0.4 of tokei. Did you have smth running on your machine that may have interfered with the response time ? Do you get the same results every time ? I mean technically it's almost as if we were running tokei inside of onefetch so the RT(onefecth) should be RT(tokei) + Overhead

[spenserblack]

I did clone linux at --depth=1, which may positively impact onefetch's behavior.

[spenserblack]

Alright, cloned at --depth=50 now, and noticed that onefetch seems to be consistently 2-3 seconds slower than it was at --depth=1 (same onefetch build I was previously using). So I'm thinking that maybe either sheer number of commits or the size of the deltas in the repo is the biggest factor for slowing down onefetch in the linux repo.

[o2sh]

In order to get a better picture of the Response time's distribution among function calls. I added a little telemetry (available on this branch) to detect the 'hot' spots 💥 where onefetch is struggling.

Here are the results for the Linux repo:

o2sh:~/dev/linux (master) $ onefetch 
get_language_stats --> 2.696831215s
get_configuration --> 24.528µs
get_current_commit_info --> 1.132701ms
get_authors --> 9.683836222s
get_git_info --> 1.874656ms
get_version --> 1.41074ms
get_commits --> 6.315069997s
get_pending_pending --> 128.824896ms
get_packed_size --> 20.631127ms
get_last_change --> 1.778009ms
get_creation_time --> 9.860741358s
get_project_license --> 88.195828ms

...and the culprits are: get_creation_time > get_authors > get_commits

[spenserblack]

git log --reverse, used by get_authors, does seem to have a large performance impact in the Linux repo. Even at a depth of 50, it takes about half a second to create a reverse log, while a normal log is instantaneous. I'm not at all familiar with the git2 crate, but, looking at the docs.rs, I wonder if interaction with repo history via the References iterator would be faster than running git log commands. For example, assuming References are sorted chronologically,

let repo: Repository; // declare repo
let first_commit = repo.rev().next().unwrap().peel_to_commit().unwrap();

Again, unfamiliar with git2, so not sure if this would work. But using a Rust iterator, which lazily evaluates its items, might be faster than executing git commands.

[o2sh]

I wonder if interaction with repo history via the References iterator would be faster than running git log commands

It's an idea worth exploring. Especially considering that git log is at the core of two of the slowest info line functions: get_creation_time and get_authors. This is a one stone two birds opportunity 💯