octocrab

octocrab copied to clipboard

Any ideas what could make it this slow? From a quick glance to the code I couldn't see anything obvious.

It should be just building a http client, correct?

let start = std::time::Instant::now();
let client = octocrab::Octocrab::builder()
    .personal_token(site_config.oauth_token.to_string())
    .build()?;
octocrab::initialise(client);
let elapsed = start.elapsed();
println!("Elapsed: {} ms", elapsed.as_millis());

Output

Elapsed: 330 ms

Thank you for your issue! No I'm not aware of anything. You might want to use something like cargo-flamegraph to see exactly what is taking up time

I can confirm this is a problem with octocrab. My hyperfine results went from

> hyperfine 'ferium list'
Benchmark 1: ferium list
  Time (mean ± σ):     405.0 ms ±   4.5 ms    [User: 240.5 ms, System: 31.1 ms]
  Range (min … max):   398.9 ms … 413.0 ms    10 runs

to

> hyperfine 'ferium list'
Benchmark 1: ferium list
  Time (mean ± σ):      16.9 ms ±   2.2 ms    [User: 7.5 ms, System: 6.4 ms]
  Range (min … max):    13.3 ms …  24.8 ms    124 runs

by just commenting out the octocrab initialisation, there were no other modifications. This is on the latest version 0.29.1 and I've been having this problem for a while at this point. It's very noticeable in use too.

~~Also I wasn't able to run flamegraph because it doesn't seem to work on macOS?~~

@theRookieCoder Im pretty sure it does given their documentation mentions it and I have used it before on macOS.

You might want to make sure you're running as superuser. https://github.com/flamegraph-rs/flamegraph#dtrace-on-macos

full flamegraph

Looks to me like some sort of macOS process is taking a ton of time, I wonder if this replicates on linux and windows.

Interesting, I wonder what's calling that, we don't use that directly, so I have to assume it's some https thing.

@raine Were you also on macOS?

Yes

Here is an image of a trace.

It shows this is coming from rustls which calls load_native_certs, which, for macOS, means going into the keychain and fetching a list. I don't know why this is slow, it might be that the APIs to fetching this data in the keychain is slow, or it might that rustls is doing something wrong here.

See also:

• https://github.com/rustls/rustls-native-certs/issues/30
• https://github.com/rustls/rustls-platform-verifier

My needs were quite modest so I solved the problem by writing a small Github client from scratch with reqwest, which for some reason does not have this delay. Perhaps it uses native tls instead of rustls.

Can you try running with features = ["rustls-webpki-tokio"]? This should bypass loading of native certs, and instead use a bundled Mozilla trust chain.