Rust http library with least compile time impact?

1

I am looking for recommendations for Rust http library to use. The requirements are:

  1. support GET POST PUT
  2. support placing cookies on client side
  3. support websockets

and, given the above, to have the least compile time overhead (tokio/hyper is a bit too expensive due to compile time)

Currently I am using: https://crates.io/crates/tiny_http

Suggestions ?

2

Why are you focusing on compile time? Something like tokio/hyper would only need to be compiled once; the only additional cost on each further build would be linking.

1 Like
3

I was not clear, by 'compile time' I meant 'incremental build time' when I hit 're-run last test in IntelliJ'.

Having tokio/hyper as a dependency appears to increase this by single-digit seconds.

I may be doing something wrong. If you have a crate that uses tokio/hyper, make a small change in your crate, and hit re-build, how much does tokio/hyper add to that build time ?

4

In my experience it doesn't add much. As I said the only thing that should be impacted is linking in the incremental scenario.

5

Maybe I am doing wrong:

  1. I create a simple app using warp. This brings in tokio, tokio-stream, futures-util, all which I am building with features=["full"]

  2. I build the crate. Initial build. This takes a while.

  3. I modify one route in warp. I hit recompile. This ends up being 4-5 seconds, for the incremental rebuild (at this point, all dependency crates have been built, and this is just the cost of compiling current crate + linking everything together).

  4. Is 4-5 seconds normal for a incremental rebuild ?

6

Yes, I would say so. How big is the binary? I have my own http-parsing code I use for development. It's a bit dodgy, although I am working on it.

7

If I am reading RustDB/Cargo.toml at main · georgebarwood/RustDB · GitHub correctly, it looks like:

  1. You are not using warp.
  2. You have hyper commented out.

I am not convinced your recompile times are a good measure of warp recompile times.

8

I am using axum, hyper, tokio etc. in one of the examples, but not in the other. It's a bit of a mess, but the simple test program uses the WebQuery module, which has dodgy http parsing builtin. The other example uses axum etc. and compiles/links slower.

I just did this:

C:\Users\pc\rust\rustdb>cargo run --example test
   Compiling rustdb v0.1.27 (C:\Users\pc\rust\rustdb)
    Finished dev [unoptimized + debuginfo] target(s) in 2.57s
     Running `target\debug\examples\test.exe`
error: process didn't exit successfully: `target\debug\examples\test.exe` (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)
^C
C:\Users\pc\rust\rustdb>cargo run --example axumtest
   Compiling rustdb v0.1.27 (C:\Users\pc\rust\rustdb)
    Finished dev [unoptimized + debuginfo] target(s) in 4.97s
     Running `target\debug\examples\axumtest.exe`

You can see including axum etc. takes the compile/link time from 2.5 seconds to 5 seconds.

Strangely, for --release, the times come out almost the same ( around 9 seconds ).

Sizes of the binaries, release test=882kb, axumtest=2,477kb, debug test= 1,854kb, axumtest=6,681kb.

1 Like
9

Correct, I am not using warp, it is using axum, which I think is roughly equivalent ( I am pretty vague about the differences ).

Yes, but axum is based on hyper, so it is used, just not a direct dependency.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.